Quoth Michael Shapiro on Thu, Oct 26, 2006 at 10:27:59PM -0700: > I'm not in favor of this without a more explicit discussion about NFS's > problems and how else they might be solved. I don't like this for the > following reasons: > > - I'm concerned about it getting used everywhere as a way for not properly > supporting smf semantics, e.g. not doing templates, not factoring properly
Actually I think it's only necessary when proper factoring has occurred. > - One of the major goals of SMF is to provide a programmatic and/or scriptable > interface to higher-level frameworks: if anything can declare itself locked, > then how is an admin script, profile, or higher-level framework supposed to > operate on it at all? (i.e. the share(1M) command isn't scriptable in the > same way, in that it doesn't support use at install/upgrade-time, etc) If someone needs to write a script to manipulate the NFS system, then in order to do it by manipulating the repository properly, he has to understand the implementation of the NFS system and the relationship of its components. It seems to me that avoiding proliferation of this knowledge is precisely the reason for existance of the share(1M) command. If people need to do this, then share(1M) should be extended. > - There are two kinds of coordinated changes: interrelated properties, and > interrelated services. Interrelated properties need to be handled by the > service itself, its method, or constrained by the future templating > features. I agree. In fact, I would say that templates are a good, cheap way to achieve the functionality of a higher-level tool like share(1M). But if the constraints are more sophisticated than templates are able to handle (e.g., coordination with files outside the repository), then it seems that a tool is necessary anyway. > Interrelated services are indeed tricky, but often if something is wrong > here it suggests that perhaps the factoring hasn't been done right. I disagree. For turning services on and off, it's really because the correct factoring of features along error boundaries leads to independent components which SMF allows access to through the generic svcadm & svcs commands that we have this problem in the first place. > 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. Now the SMF team has already recognized this 'feature' problem, because it has already come up a few times (NFS, SVM, routing, and soon, wpad), but we're not sure what to do about it. We thought that the most immediate need would be "Visual Panels", since people don't really want to configure each individual SVM daemon -- they want to configure the SVM feature. But this is coming up again in the design of the Enhanced Profiles project, which is what lead to this. Perhaps SMF should grow virtual services which represent a bunch of other services. Like milestones, except with richer semantics. But for now at least, feature-specific commands which interact with SMF is both easy and backwards compatible. And a kicker: It also seems to me that this feature would be desireable for the SMF framework itself. Do you know that you can use svccfg to change the reported state of a service to an arbitrary string? That doesn't seem right. It seems that svc.startd should lock all of the state that it publishes so users who try to change them will immediately learn that the right way to change it is via svcadm. David
