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:  vorner
                       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:  9
Feature Depending on Ticket:         |           Total Hours:
        Add Hours to Ticket:         |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by vorner):

 Hello

 Replying to [comment:16 jinmei]:
 > There were too many changes and too many removed tests, so it was
 > difficult to be confident about compatibility, stability, regression
 > freeness, etc...(some were already noted in the tickets, and I'm okay
 > with deferring compatibility support for some of the existing ones,
 > but I'm still now sure if the rest of the changes are okay in terms of
 > this sense).
 >
 > Maybe it was deemed to be too difficult or simply impossible, but due
 > to the above concerns I'd still like to try step-by-step transition.
 > A possibility would be:
 > 1. first merge the component module (this should be safe,
 > 2. choose a small part of the existing functionality, and replace only
 >   that part with the new module.  do it carefully by preserving the
 >   semantics of the original test as much as possible.  Maybe we should
 >   initially simply add code to call the corresponding component module
 >   but do nothing, then confirm the behavior with tests, and then
 >   remove the old code while letting the component module do the real
 >   job.
 > 3. repeat the 2nd process until we remove all old code.

 I don't know how to do it well. I did write the module first (and I think
 it could be merged first, if it makes any difference), but I had enough
 hard time getting through the boss code to start by plugging it in by
 parts, finding out that it breaks it completely, because then the two ways
 mostly collided (like the way processes are stopped differed, the way
 terminated processes were handled) and it turned out that mostly two
 copies of the code (the old and the new one) would need to coexist.

 My original history contained some of these steps and situations where
 they coexisted a little bit (with large parts being broken at the time),
 but I removed these temporary parts of code so the diff is more readable
 and reviewable. If you'd like, I can try to look into the git internals if
 it's still there.

 The removed tests were removed simply because they were testing something
 that no longer makes any sense and does not exist. There's no test to see
 if resolver (for example) is started, because the boss now has (almost) no
 knowledge about existence of resolver. It tests that a component
 configuration is passed to the configurator (which might be a resolver or
 whatever else, the boss doesn't care) and the configurator should be
 tested quite a lot.

 It is true the boss is probably tested less than it should.

 > And one more thing: Do we need a changelog entry for this task?  Or is
 > the plan to provide it when we complete the entire migration?

 Possibly. There should be a changelog in the end, because it's a really
 well visible change, but I'm not sure when. If we decide to go with the
 big branch way, maybe when merging back to master. If we choose to merge
 now, maybe I'd add a changelog then. But I'd rather like to add it when
 there's a little of documentation for a user somewhere to point to it.

 > I don't understand the trick here:
 > {{{
 >     LIBEXECDIR = ("@libexecdir@/@PACKAGE@"). \
 >         replace("${exec_prefix}", "@exec_prefix@"). \
 >         replace("${prefix}", "@prefix@")
 > }}}
 > The relationship between @libexecdir@, ${exec_prefix}, @exec_prefix@,
 > ${prefix}, and @prefix@ is not clear.  Please add comments about the
 > intent.

 This was handled in the boss by a trick from Makefile, which I didn't
 like. But it turned out the replacement (the things in @@) happened to
 contain more and more variables and I kind of continued to replace them
 until it stopped. Do you think it is OK (with a comment) or I should find
 a better way to do it?

 > - Some of the removed log IDs seem to still remain in the message
 >   file.  e.g.
 > {{{
 > -        logger.info(BIND10_CONFIGURATION_START_AUTH,
 self.cfg_start_auth)
 > -        logger.info(BIND10_CONFIGURATION_START_RESOLVER,
 self.cfg_start_resolver)
 > }}}
 >   (There seem to be more) These orphan messages should be identified
 >   comprehensively and cleaned up.

 I grepped them out, I left only the BIND10_START_AS_NON_ROOT, as I'd like
 to reintroduce the message.

 > - `BoB.__init__()`: ideally I'd like to move the setting of
 >   `__core_components` outside of the bind10 module (and even more
 >   ideally make it "configurable" by a command line option, etc).

 I don't think configuration on command line makes any sense. These are the
 real core components. The boss won't be able to work (and load the
 configuration) without them. I don't see a reason why boss shouldn't know
 the bootstrap process and why a user would want to modify it (or in which
 way it would make any sense). In fact, I'd like to keep users as far from
 these as possible. If anybody has a reason to have a different set of
 these in bootstrap process, they are coding already anyway. I don't expect
 even the authors of additional bind10 components to need to modify them.

 > - config_handler(): I'm often confused about this point, but doesn't
 >   this callback only get the difference from the current
 >   configuration?  If that's the case, I suspect it doesn't meet the
 >   assumption of the component module, that is, it could accidentally
 >   kill a running component.

 It gets all the modified top-level items, but they are complete. So, the
 components config is there complete or is not there at all.

 Thanks (there'll be more coming).

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