BIND 10 #1342: Reintroduce delayed restarts after #213

BIND 10 Development do-not-reply at isc.org
Wed Nov 16 15:47:15 UTC 2011


#1342: Reintroduce delayed restarts after #213
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jelte
  vorner                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20111122
                   Priority:  major  |            Resolution:
                  Component:  Boss   |             Sensitive:  0
  of BIND                            |           Sub-Project:  Core
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:         |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jelte


Comment:

 Replying to [comment:10 jelte]:
 > Replying to [comment:9 vorner]:
 > > I guess you see no way to test the boss code itself as unittest?
 Anyway, you might want to check how components interacts with various
 kinds and being killed sooner or later.
 > >
 >
 > There may be a way to do it, I may be able to come up with a mocky
 > thingy, but either that would mostly be testing the mock itself, and I
 > think having a test that actually kills a process from the outside
 > would be more useful.

 In the second sentence, I meant more like the stuff in
 lib/python/isc/bind10/components.py. There are quite few changes, but not
 many tests for it. There should be something to see that if it is
 restarted, the _original_start_time isn't changed, that it is None before
 the first start, the starts sets it, that a core component doesn't get
 restarted or return True, etc.

 > > Actually, I found a problem with the behaviour. If I choose a needed
 component (let's say b10-auth in the default configuration) and kill it
 later than 10s after the system started, it is restarted. If I kill it
 again soon afterwards, the system stops. However, the semantics of needed
 component was to stop only if it fails at startup (with 10s being large
 enough time to fit the initialization in there probably), when the user
 typed the command and can see the system is ill. But this might happen
 after the user went for a holiday, so in this case it shouldn't bring the
 system down.
 > >
 >
 > Heh. I *knew* it was too convenient that that variable existed already
 > :)

 :-)). Well, I heard one should be wary about the things that come for free
 ;-).

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


More information about the bind10-tickets mailing list