>
> > So before we go add this, I'd like to see a detailed discussion of exactly
> > what issue NFS is having and let's apply first principles to that.
>
> Sure. I think the root problem is that SMF asks developers to divide
> their features up along error boundaries and then automatically presents
> the resulting pieces to the user through svcs & svcadm. This works
> great for most services since they are self-contained. telnetd, for
> example, implements a feature all by itself, so being able to use svcadm
> to turn it on and off is appropriate and a boon. NFS, on the other
> hand, is implemented by multiple daemons. Setting sharetab aside for
> a moment, the NFS developers could choose to pack all of them into the
> nfs/server service, in which case using svcadm to turn it on or off
> would be appropriate. But then they wouldn't get individual-daemon-
> restart semantics. For that they have to put each daemon into its own
> service. And then they get the accidental user interface into the
> implementation of the feature. Perhaps a better way to talk about this
> problem is by saying the NFS developers should be able to declare the
> general/enabled property of its services as less than public, in
> response to which svcadm & svccfg would advise the user about the
> correct way to achieve the property modification.
>
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_.
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)
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.
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.
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
