I've done some more thinking (and coding) regarding temporary
configuration of SMF services, and I'm beginning to suspect it's just
too evil to work with, at least for now.
Given a "temporary instance" design that's implemented as a real
instance, but with the service disabled in the repository, what
happens when the user does this to a regular (non-temporary) instance?
svcadm disable svc:/network/bridge:foo
svcadm enable -t svc:/network/bridge:foo
Does that turn it into a temporary, causing it to lose its moorings
unexpectedly? What happens in the reverse case (or is being able to
sediment a temporary just an unexpected "feature?")?
And then come the questions about why I can configure an instance that
is itself temporary, but I cannot set temporary changes to parameters
on a non-temporary instance -- because I can only have one property
group with a given name, and a group can only be temporary or
permanent, not both. Isn't it just as likely that I'll want to do
that?
Existing administrative model for plain-text-file-based services be
darned; I'm not going to wander about in these woods without framework
support, so I'll just drop the "temporary" scheme as unworkable for
now. If you want bridges, darn it, you'll just have to configure them
normally like the rest of us.
Thanks for at least forcing me to think this one through.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
