Quoth Alan Maguire on Fri, Aug 11, 2006 at 04:56:15AM -0700:
> > So, at a high level, what we'd propose is
...
> >       - new routing/legacy:ipv4 and routing/legacy:ipv6 service instances
> >         to collect routeadm configuration for legacy daemons
> >
> >         default configuration as disabled, with methods set to :true,
> >         'contract' duration.  routeadm can set start/exec, options/
> >         args, and stop/exec properties based on user input, then
> >         enable the service
> 
> this is a _really_ great idea!

I think you'll actually have to store the daemon path in a property
other than start/exec, and have start/exec set to a script which returns
the appropriate error codes, since the legacy service's exit codes will
probably not conform to the SMF interface.

> >  - use routeadm as the actor for administrative intent
> >      routeadm -e/-d looks up the protocol->service/legacy service
> >       mapping, and takes care of explicitly enabling the appropriate
> >       services.  -e/-d doesn't need to do fmris directly, since
> >        -s ipv4-routing-daemon=fmri would work.
> 
> one little complication here - the smf routing daemon services
> would have to remove themselves from routeadm's list in their
> stop methods, otherwise the following sequence would lead to
> unexpected behaviour.
> 
> # routeadm -s ipv4-routing-daemon="route:default"
> # routeadm -e ipv4-routing -u
> # svcadm disable route:default
> # reboot
> 
> (in this case, if route:default's stop method didn't remove itself
> from the list of v4 routing daemons, on reboot it would be
> reenabled when "routeadm -u" is run).

Indeed, when intent is spread across multiple locations,
synchronizations problems appear.  So one of the ideas here is to
concentrate intent in as few places as possible.  Since we can't get
around the general/enabled property for each individual service, rather
than having routeadm keep a list of services, it should derive that list
from the general/enabled properties of the services.  So the svcadm
disable route:default, in this case, should be interpreted the same as
routeadm -d ipv4-routing -u.  (Note that this is just like inetadm's
enable/disable behavior.  In essence, routeadm is just a convenience
tool for being able to separate the enable part from the
which-implementation part.)  This may also eliminate the need for
routeadm -u on boot.


David

Reply via email to