BIND 10 #1596: Addressing of multiple instances of the same component

[BIND 10 Development]

#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):

 Replying to [comment:11 vorner]:

 > > - auth_log.h: not a big deal (and not really specific to this ticket),
 > >   but I wonder why we define local log levels like this:
 > > {{{#!c++
 > > // Debug messages upon shutdown
 > > const int DBG_AUTH_SHUT = DBGLVL_START_SHUT;
 > > }}}
 > >   especially now that we have use this value for two purposes.  Why
 > >   can't we simply use DBGLVL_START_SHUT for both cases?
 >
 > I think for historical reasons, we didn't have the DBGLVL_START_SHUT at
 the time when most of the logging was written and when they appeared, the
 local constants were just updated. I didn't want to break the consistency
 with them and I don't want to go through the whole auth and modify them
 there, the cleanup change would be too big to piggy-back it I think. Maybe
 another ticket (the tickets seem to grow exponentially this way, every
 ticket has multiple follow-up tickets).

 Not updating this branch for this is okay.  The ticket bloat issue is
 true, but I can't think of a better way to make a good balance between
 ensuring quality and reasonably rapid integration.  In many cases,
 however, cleanup tickets are trivial and much easier than the original
 one.

 > > - AuthCommand::exec: in general, I'd rather prefer rejecting bogus
 > >   inputs (either as a result of exception or by returning a specific
 > >   error) than ignoring them.  In the case of auth, it should actually
 > >   have been so because Element class would throw an exception (and it
 > >   will be caught in execAuthServerCommand(), logged, and translated
 > >   into an error answer to the command issuer).  Same comment applies
 > >   to the resolver, although in that case we (probably) cannot simply
 > >   throw an exception because it wouldn't be caught in a proper
 > >   context.
 >
 > I changed it to throw the exception (and added the catch for the
 resolver, it can't hurt).

 Okay.

 The branch now looks basically okay.  I've noted a few more minor
 things, but I'd leave it to you whether/how to address them.  After
 addressing them (or not) please feel free to merge.

 - bind10_src: in my often incorrect understanding of the English
   grammar, an 'if' clause cannot be the subject of a sentence.  So I'd
   change 'If it turns...or if we' to "Whether it turns...or whether
   we":
 {{{
        # want to support multiple instances of a single component. If it
 turns
        # out that we'll have a single component with multiple same
 processes
        # or if we start multiple components with the same configuration
 (we do
        # this now, but it might change) is an open question.
 }}}
 - in auth command test, I'd initialize expect_rcode_ in the
   constructor based on the spirit of initializing everything as soon
   as possible.
 - Now we catch exceptions from the CC/element module at a reasonable
   level, we could even omit this check, which would make the main code
   a bit more concise:
 {{{
 args->getType() == isc::data::Element::map &&
 }}}

-- 
Ticket URL: <http://bind10.isc.org/ticket/1596#comment:12>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development