BIND 10 #1596: Addressing of multiple instances of the same component
BIND 10 Development
do-not-reply at isc.org
Thu Feb 9 01:39:11 UTC 2012
#1596: Addressing of multiple instances of the same component
-------------------------------------+-------------------------------------
Reporter: | Owner: jinmei
vorner | Status: reviewing
Type: task | Milestone:
Priority: major | Sprint-20120221
Component: | Resolution:
Unclassified | Sensitive: 0
Keywords: | Sub-Project: DNS
Defect Severity: N/A | Estimated Difficulty: 5
Feature Depending on Ticket: | Total Hours: 0
Multiple auths |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Comment (by jinmei):
First off, I made a few trivial changes to the branch.
'''higher level points'''
- When I tried to add an additional b10-auth process (from the source
env):
{{{
> config add Boss/components b10-auth-2
> config set Boss/components/b10-auth-2/special auth
> config set Boss/components/b10-auth-2/kind needed
> config commit
}}}
with the attached config (it uses non privileged port), two
processes in fact ran, but only one of them seemed to listen on:
{{{
% lsof -n | grep b10-auth|grep IPv4
b10-auth 97674 jinmei 11u IPv4 0x0fc42788 0t0 TCP
127.0.0.1:hacl-hb (LISTEN)
b10-auth 97674 jinmei 12u IPv4 0x0ea86294 0t0 UDP
127.0.0.1:hacl-hb
}}}
I also saw this error in logs:
{{{
2012-02-08 17:20:18.508 INFO [b10-boss.boss] BIND10_SOCKET_GET requesting
socket [::]:53 of type TCP from the creator
2012-02-08 17:20:18.509 ERROR [b10-boss.boss] BIND10_SOCKET_ERROR error on
bind call in the creator: 13/Permission denied
2012-02-08 17:20:18.509 ERROR [b10-auth.server_common]
SRVCOMM_ADDRESS_FAIL failed to listen on addresses ("Error creating socket
on bind")
}}}
I stopped it once and restarted it, but the situation was the same.
If restarted it as a root, one of b10-auth listens on the privileged
port:
{{{
% sudo lsof -n | grep b10-auth|grep IPv4
b10-auth 97589 root 16u IPv4 0x0fc41748 0t0
TCP *:domain (LISTEN)
b10-auth 97589 root 17u IPv4 0x0ea86294 0t0
UDP *:domain
b10-auth 97605 root 11u IPv4 0x0f4adad8 0t0
TCP 127.0.0.1:hacl-hb (LISTEN)
b10-auth 97605 root 12u IPv4 0x0d669658 0t0
UDP 127.0.0.1:hacl-hb
}}}
- It'd be convenient if I could differentiate different instances of
the same type of process in logs.
- I'm now feeling I'm confused. What was the expected relationship
between components and processes? I thought a single component can
consist of multiple (same type of) processes, but the updates to
bind10 and component.py seem to assume it's one-to-one
relationship. Comments and documentation also seem to be not very
consistent. bind10_src.py says:
{{{#!python
# Some time in future, it may happen that a single component has
# multple processes. If so happens, name "components" may be
# inapropriate. But as the code isn't probably completely ready
# for it, we leave it at components for now.
self.components = {}
}}}
which seems to support the one-to-multi design. On the other hand,
component.py says:
{{{
This framework allows for a single process to be started multiple times
(by
specifying multiple components with the same configuration). However, the
rest
of the system might not handle such situation well, so until it is made
so,
it would be better to start each process at most once.
}}}
which seems to support the one-to-one mapping.
- As for the testability of resolver, I see it's difficult with the
current implementation architecture. For a longer term, I
personally think we should unify command/config submodule for auth
and resolver and share as much code as possible. But in any case
it's beyond the scope of this task.
- A related note: since this feature involves multiple processes, I
think we need system tests. Then we can also test the resolver at
least at the higher level. It could be okay to defer it to a
separate task, but I think it should be done pretty soon (e.g., in
the next sprint).
'''auth_srv.h'''
Just checking: why did you remove this? Because it's trivial?
{{{
- /// \return the value of the counter.
+
}}}
'''auth/command.cc'''
- Is there a rationale for the ordering between <string> and boost
headers? Also, if the basic rule is "if header A (possibly) depends
on header B, include A first", dns/ headers should be included much
later. Same for exceptions.h. Same for other files.
- what if args is bogus (e.g. pid is not int, perhaps there can be
other bogus cases)? it should be tested. same for resolver, and I
suspect it can be more devastating because exceptions won't be
caught at a lower level.
- maybe we should log the shutdown event? Especially if the wrong pid
is not expected to be delivered (I was not sure about that), that
would be worth noting.
- ShutdownCommand::exec: to me this would look more natural when it
fits in a single line:
{{{#!c++
if (args && args->getType() == isc::data::Element::map &&
args->contains("pid")) {
}}}
but if you had a particular preference with that style I don't
object.
- ShutdownCommand::exec: I'd rather save a few lines by not
introducing pid and my_pid. again, it may be a matter of
preference.
'''command_unittest.cc'''
- If we add a prefix of `_` to itimer (which is probably a good
practice - I was confused when I saw 'param' in a test), maybe we
should be consistent.
- AuthCommandTest::shutdownCorrectPID: another matter of taste, but I
don't need the temporary 'param' if we make the member 'param'
variable mutable (normal ElementPtr) and reset it.
'''component_test.py'''
- Is it okay to only check if pid is None to be sure if the PID is
really passed in the non-test environment?
'''bind10-guide'''
- do we need to regenerate and merge HTML in individual branch?
- I suspect there's no SQLite3 locking issue due to using multiple
auth instances (at least for now auth only uses it for read-only, so
multiple auth instances shouldn't content each other). But the
guide says "could be", which is basically always correct by
definition, I don't oppose to that if you really want to mention
that possibility.
'''changelog'''
Maybe "core" is more commonly used than CPU today? (even though
"multi-core" has also limited meaning). Not a strong opinion anyway.
--
Ticket URL: <http://bind10.isc.org/ticket/1596#comment:6>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list