routing / routeadm configuration is made up of a large number of
components which can all fail and should be restarted separately.
Furthermore, the configuration of these components is related, but not
necessarily in a simple or straightforward way.
You've done a *really* admirable job of trying to make the SMF
administrative model to configure routing reduce to a small set of commands.
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.
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.
Without some fundamental framework support, I'm not convinced there's a
good resolution which allows you to create services which operate on
appropriate fault boundaries (a service instance per running daemon),
plus offer the sort of large-scale SMF knobs that you've defined.
So, at a high level, what we'd propose is
- no global routing service
- define services on fault boundaries. e.g.
- service instance per routing daemon
options stored as separate properties on these instances
- 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
- transient static routing service
- transient forwarding service
- 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.
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
appropriate ndd knobs should be twiddled through the appropriate
services based on administrative intent
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.
(I'm unfortunately going to be away from email from this evening until
Monday morning. However, this writeup is meant to be a synthesis of
opinions, and others who participated in the synthesis like David
Bustos and Dave Powell should be around to continue and clarify any
particularly opaque points.)
liane
--
Liane Praza, Solaris Kernel Development
liane.praza at sun.com - http://blogs.sun.com/lianep
