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