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 vorner):

 Hello

 Replying to [comment:31 jinmei]:
 > >  - The start_all_pracesses method starts only b10-auth, not all the
 xfrin, xfrout, etc. That doesn't seem to matter much, as the configuration
 handler is called soon enough anyway. Is there a reason for this? Anyway,
 this is temporary, so it doesn't matter.
 >
 > I thought they started as a result of this:
 > [...]
 > didn't they?

 Ah, right. I got confused when it was separated, the first condition with
 start_auth looked too short O:-).

 > BTW, in this sense the resolver part was incorrect.  I intended to call
 > `self.__propagate_component_config` here, too:
 > {{{
 >         if self.cfg_start_resolver:
 >             component_config['b10-resolver'] = { 'kind': 'needed',
 >                                                  'special': 'resolver' }
 >             self.started_resolver_family = True
 > }}}

 Added and tried manually.

 > >  - The start_xfrin in master now has some kind of hack with paths.
 Should we preserve that one?
 >
 > Yes, we should, unless #1292 is resolved soon.

 I returned the workaround by creating an xfrin special component. The
 start should be tested by system tests (there are some testing xfrin
 specially). However, my system does not check the workaround itself.

 > > Hmm, I'm not sure about that. Actually, I envisioned the component
 could have more than one process running (in which case it would register
 multiple times) or no process at all. So, doing this would decrease the
 flexibility. Should I document this idea somewhere?
 >
 > Yes please.  I'd leave it to you whether to update the code itself.

 Added a comment.

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