hi Liane thanks a million for this, i _really_ appreciate the specific suggestions!
> However, you've had to resort to lots of tricks/hacks in order to get it to > work at all. As you've surely noticed, currently SMF doesn't provide you > with any real support for managing collections of related services, and > I think that the routing/forwarding collection is one of the most > sophisicated collections so far. yeah, i guess the problem stems from the fact that routeadm has many of the properties of a delegated restarter (kicking off daemons etc), without itself comprising functionality that those daemons rely on (bar the properties that specify if routing daemons should run) - contrast this with inetd where inetd services need inetd to run to work properly. > I think most of the unease I'm feeling about the current solution > (as I've constructed it based on the mail trails) is due to these tricks > you've needed to pursue. I'm worried that these tricks lead to > inconsistent administrative cases at the boundaries. You're stuck storing > configuration like whether ipv4 routing is enabled in two places: on the > general/enabled property of the collection of routing daemon services, plus > as an administrative-intent knob on the routing:default service. agreed - most of these tricks are to make the global routing service a kind of "lightweight restarter". > So, at a high level, what we'd propose is > - no global routing service ok. > - define services on fault boundaries. e.g. > - service instance per routing daemon > options stored as separate properties on these instances sure. on this topic, i've asked a question about breaking out opaque daemon argument strings into meaningful daemon properties, see: http://www.opensolaris.org/jive/thread.jspa?threadID=11505&tstart=0 i've suggested an approach that i think will work for routing daemons. any thoughts people have would be greatly appreciated! > - 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! > - transient static routing service sure. > - transient forwarding service makes sense. > - 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). this is just an implementation issue for the daemon methods though. > routeadm's status view is based on that lookup plus the status of > the services > if routeadm needs better high-level knobs, it grows them like > you've proposed yeah, i think if we just add dynamic_routing, static_routing and routing properties we should be covered. # routeadm -d routing would disable ipv4-routing/ipv6-routing/static-routing while # routeadm -d dynamic routing would just disable ipv4-routing/ipv6-routing > appropriate ndd knobs should be twiddled through the appropriate > services based on administrative intent yep. > That is, we propose you keep routeadm as the primary administrative > interface until SMF can offer you an appropriate set of abstractions. > It isn't too far from your current design, so I hope it's reasonably > acceptable. seems fine to me. i'll respin the design document, and point people at it when i'm done for comments. thanks so much! alan This message posted from opensolaris.org
