Quoth Michael Shapiro on Fri, Oct 27, 2006 at 04:13:14PM -0700:
> I need to hear more details on what specific things they expect to work and
> not work. In general, it sounds to me like you're describing the same type
> of thing I discussed with the ipfilter and routing people, which is the
> tension between service fault boundary and the idea of a single command
> to enable/disable a feature. I won't recap the principles here (refer to
> the earlier thread), but the bottom line is that we never established
> any rule or idea that one can arbitrarily type "svcadm enable X" or
> disable X for arbitrary X and that is the same as turning on or off
> some feature _as the administrator understands the top level concept_.
That's easy for us to say, but doesn't it set the administrator up for
failure? Aren't you suggesting that the workflow for disabling
a service that an administrator sees running via svcs should be
1. Run svcs -x on the FMRI to get the manpage.
2. Read the manpage to see whether svcadm should be used on the
service or not.
3. Use svcadm if appropriate, or otherwise use the feature-specific
tool as indicated by the manpage.
This is the antithesis of approachability, and administrators aren't
going to do it. We should throw them a bone by telling them when it's
a bad idea to use svcadm ASAP, like by failing the svcadm.
> If a feature is composed of N pieces that can fail independently that are
> separate service boundaries, then:
>
> (a) You can of course have a meta-command which configures the entire
> thing (albeit with the necessity to be aware of the transaction
> boundaries)
>
> (b) The service needs to handle independent service disable/failure anyway
> because one item could enter the maintenance state
>
> (c) Administrators can't assume that typing enable N1 or N2 (parts of the
> larger N) disables or enables the entire thing. The documentation
> should guide them towards what the appropriate activities are. But
> svcadm should not be preventing someone from doing from doing that,
> because there *are* legitimate reasons to do (e.g. install/upgrade,
> develop/debug, the need to develop more sophisticated higher-level s/w)
Install, upgrade, and higher-level software should use the same
interface that share(1M) uses, if they know what to do better than
share(1M) does. For development or debugging, the protection can be
turned off, since it's set by the developer anyway.
> Fundamentally from the point of view of the service developer, handling
> independent disable as in (c) doesn't require doing anything different,
> because you *already* have to handle (b), so that code needs to be there.
That's right. The point of this proposal is how it appears to the
administrator. Does the system let him do something unsupported and
then put a bunch of services into maintenance? Or silently undo what he
has done? Or does the system say, "sorry, use the appropriate interface"?
> General points aside, we can best discuss NFS by seeing a list of specific
> behaviors we're trying to support or discussing the failure boundaries.
I would rather add features to the framework in a generic fashion. I'm
only using NFS here as a concrete example; I could just have easily used
SVM, routing, or wpad.
David
