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-20111108
                  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 jinmei):

 Replying to [comment:20 vorner]:
 > Hello
 > > There were too many changes and too many removed tests, [...]
 > >
 > > 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've created a kind of quick hack branch ("trac213-incremental") to
 see how the step-by-stp approach was difficult or could be feasible.
 It begins with the latest component stuff and the master version of
 boss code, and modifies the latter so that only the start and stop
 processes are updated to use the component/configurator framework.

 It doesn't yet introduce any new configuration syntax, and restart is
 still handled in the old way.  In that sense it's incomplete, but it
 keeps all existing tests with a relatively minor modifications so we
 can be more confident that it doesn't break the existing behavior.  In
 fact, it passes system tests, too.

 This is a kind of proof-of-concept stuff and I'm not saying we should
 do this exactly the way I did in that branch, but to me it proved we
 could effectively make the changes more gradually.  On top of the
 first small changes like the ones in the "incremental" branch, we can
 then add support for restarting using the configurator/component
 modules.  We can also then update the boss configuration syntax so
 that we can replace the old style with the new one.  Throughout the
 process, we'd be able to replace "the tests that no longer make sense"
 with corresponding new ones more gradually, thereby making us believe
 it's safe migration.

 Isn't it possible we can once step back to something like this and
 rebuild the things one by one?  If you still think it's impossible...,
 I don't know how we can move forward.  Frankly, the size of the
 changes exceeded my brain capacity.  Maybe we should find another
 reviewer, or you might divide the diffs into several sets so I can eat
 them one set to another.

 BTW, in either case I believe we need commit c916095.  Without this
 killing the boss process by a single would also kill sockcreator, and
 it will make the shutdown process a bit unexpected (this problem
 exists in the current code, but the configurator code logic will make
 it more visible).

 > > 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.

 That's fine.

 > > 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?

 At least as long as the intent is commented I'm okay with it.

 > > - `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.

 I'm not 100% sure if we never want to modularize (e.g.) the config
 manager and make it replaceable, but I admit that may be
 over-generalization.  So I don't oppose to leaving this point as is.

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