BIND 10 #1378: Configuration of #213

BIND 10 Development do-not-reply at isc.org
Wed Nov 9 17:18:36 UTC 2011


#1378: Configuration of #213
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  vorner                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111122
                  Component:  Boss   |            Resolution:
  of BIND                            |             Sensitive:  0
                   Keywords:         |           Sub-Project:  Core
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:7 vorner]:

 > OK, I added them back (or something that should be equivalent with
 them).
 >
 > > - test_config_start_once: what's the purpose of this addition?
 > > {{{
 > > +        bob._BoB_started = True
 > > }}}
 > >   (same for test_start_dhcp, etc)
 >
 > Since the boss ignores configuration updates until it is fully started
 and it uses this variable to know it was started. We don't do the real
 startup, so we need to fake it.

 But the test passes even without this setting (btw, the same thing
 applies to `runnable`).  And, I now realized that even if we really
 needed it it shouldn't have been correct.  It should be
 `_BoB__started`, not `_BoB_started`.  There should be some confustion
 here.

 > > '''system tests'''
 > > I guess this hack is due to a bug already fixed in master (forgot the
 > > ticket number):
 > > {{{
 > > +echo 'config add Boss/components x
 > > +config remove Boss/components x
 > > }}}
 > > I'd rather merge that fix here and remove this kludge now.
 >
 > Yes, I know about that one. I didn't want to bring in another merge
 which would make the review harder. I want to remove it at the merge with
 master (or, I'd propose waiting at last until the branch stabilizes, just
 because of the reviews). I don't want this to exist in master.

 Okay, then please make sure it's cleaned up on merge.

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


More information about the bind10-tickets mailing list