BIND 10 #213: Change hard-coded process startups to configuration-driven

[BIND 10 Development]

#213: Change hard-coded process startups to configuration-driven
-------------------------------------+-------------------------------------
                   Reporter:  shane  |                 Owner:  UnAssigned
                       Type:         |                Status:  reviewing
  enhancement                        |             Milestone:
                   Priority:  major  |  Sprint-20111025
                  Component:  Boss   |            Resolution:
  of BIND                            |             Sensitive:  0
                   Keywords:         |           Sub-Project:  Core
            Defect Severity:  N/A    |  Estimated Difficulty:  0.0
Feature Depending on Ticket:         |           Total Hours:
        Add Hours to Ticket:         |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => UnAssigned
 * status:  accepted => reviewing


Comment:

 Hello

 The branch took longer and grew bigger than I expected. I hope the commit
 messages and a little description helps, though.

 So, it currently looks like this:
  * There's a configurator object, that keeps track of configuration
 changes. It creates components and let them start and stop accordingly.
 This is in new `isc.bind10.component` module.
  * The components (living in the same place) are either common ones,
 starting as any other process, or they can be subclassed to support
 different types of startup.
  * The components are of three kinds, differing in the way they solve
 their failure. Dispensable one always tries to restart. Needed shuts down
 the boss if it fails to start (or crashes less than 10s after being
 started), but restarts if it happens later on. The core ones just
 terminate the system every time.
  * The old way of starting and stopping was mostly removed, only the
 functions that did the actual starting and stopping were left and are used
 from within the components. The boss just creates the configurator and
 passes the configuration there.

 However, the branch in current state has few drawbacks:
  * I had a hard time editing boss. I didn't distract myself with proper
 committing at the time, so I did some history rewriting afterwards to
 clean it up and make it slightly sane. So some commit dates might look
 strange. It also might be possible I put some of the diffs into wrong
 commits by accident, but I think it should not be much.
  * The support of brittle mode is gone. It can be simulated by setting all
 components to core, but it might be less comfortable. The tests for it are
 just disabled. We should decide if we want to reimplement the brittle mode
 (if then, this ticket, or different one?), or remove it (the command line
 option, docs and tests).
  * The support for delayed restarts is not present currently. I want to
 get the review sooner than later, but I don't think it is usable without
 this support, as when a dispensable component fails to start, it ends up
 in an infinite loop.
  * Some parts are less tested than it would deserve. They are mostly stuff
 when external processes need to be started, so we might want some kind of
 system-level tests for these.
  * There are missing parts, like:
    - Some more error handling and validation of the config would be nice.
    - Support to specify command line parameters in the configuration. The
 configuration already allows that, but it doesn't get through the
 component all the way to the thing that starts the command. This should be
 small, though.
    - We probably want to get rid of command line arguments of the started
 processes and give them their config by the usual ways. For one, we can't
 change them at runtime, for another, we might want to get rid of some
 special components for auth and resolver.
    - If we're shutting down, we might want to gather exceptions and keep
 shutting down, then pass all the exceptions at once back, or something.
 This way, if one process fails to stop, all the other's aren't stopped in
 the clean way, but killed.
    - Stopping of socket creator causes an exception often.
    - The ccsession is starting log message is wrong, as ccsession is not a
 process.
    - We might want to have a way to kill a component if it doesn't want
 comply, when the user removes it from the configuration.
    - We might want to support waiting for start/stop of a component, we
 don't do that now at all.
    - The named_set bindctl handling is buggy. I found only one way to add
 a component to the configuration, and it is providing the JSON of the
 whole component in config set. Removing a default component works only if
 the configuration is already modified.
    - There's no user-level documentation, but there definitely needs to
 be.
    - We'd need a way for the name of the process and the name on the
 message buss to correspond, this way the configuration needs to provide
 both names, which is unnecessarily verbose.
   Is it OK if I create tickets for these?

 So, my question is, is the branch bearable for review, or should I think
 of splitting it somehow (the problem is I don't see an easy way to do it,
 except for splitting it into the new components.py and the changes in
 boss, which is easy to do while reviewing). And, if the branch is
 reviewabla, what should we do with it? I think we should solve some of the
 regressions caused by the new implementation before giving it to users,
 maybe even before giving it to developers (namely the restarts, brittle
 mode and documentation). If so, we might want to do the tickets soon
 enough, branch them from here, but merge master to it from time to time
 (once a week?) to minimise the diversion.

 Thank you

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