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:  jinmei
                       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:40 vorner]:

 > > This way it's clearer what is expected to be overridden as a set.
 > > It's also safer in terms of avoiding to accidentally refer to things
 > > like _procinfo with partially overridden methods.
 >
 > This sounded like too many classes to me, it's hard to follow it. So I
 made a compromise to have a base class which has the methods which should
 not be overriden and took the procinfo and stuff to a separate derived
 class. Would this help?

 Works for me.  See comments about implementation details.

 > > I meant this comment is UNIX (or POSIX) specific while Python's
 > > subprocess class is more generic:
 > > {{{
 > >         If the forcefull is true, it uses SIGKILL instead of SIGTERM.
 > > }}}
 >
 > I updated it to say „for example“ to make it clear this is not the only
 possible way.

 OK.

 > > Probably, as a workaround (by definition as long as it works and is
 > > relatively short term, any solution should be reasonable).  Note also
 > > that the experimental 213-incremental branch has another workaround
 > > (not specifically intending to address this, but as a result of the
 > > attempt of keeping the original behavior as much as possible).
 >
 > But this workaround won't work if we move to the configurable way
 completely. Because if the list of processes is defined completely by
 configuration, the boss doesn't have the knowledge to know where to put
 the „drop privileges“ call.

 I know.  But I believe we could still leave hardcoded workaround in
 bind10_src.py that checks the given configuration and performs the
 incremental startups.  We could have more generic drop-root-priv
 components.  In either case it will be a not-too-long workaround until
 sockcreator is done, so I'd go for easier way (and basically I'm okay
 with any workable solution).

 Some comments on specific details:

 - 'boss' and 'kind' seem to be a duplicate for BaseComponent and
   Component.  For the latter we can simply refer to the BaseComponent's
   doc?
 - Msgq doesn't meet the recommendation of the Component class:
 {{{
     directly. It is not recommended to override methods of this class
     on one-by-one basis.
 }}}
   If this exceptional customization is still considered the best, I
   think we should note more explicitly that it (intentionally) breaks
   the recommendation and explain more detailed rationale than just
   saying "hackish".
 - in component tests, we now don't test the Component class itself.  I
   suspect we should introduce a mock boss object and test Component
   (that doesn't actually spawn a process or kill it, but just
   internally emulates such operations).
 - I realized it's not clear from the doc string what is expected for
   the 'info' parameter of BoB.register_process().  Right now it's a
   ProcInfo object, but it's a short term workaround, and it will
   eventually be a BaseComponent object.  It will help if we clarify
   that in the docstring.

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