Quoth James Carlson on Fri, Oct 27, 2006 at 07:52:29AM -0400: > David Bustos writes: > > SMF users and developers, > > > > What would you think about something like this: > > > > $ svcadm enable nfs/server > > Error: svc:/network/nfs/server:default is locked. > > Use share(1M) to administer this service. > > Ouch. I think your implementation details are showing. > > In general, I think the melange of internal system implementation > artifacts and external administrative interfaces implied by this sort > of change represents a problem for SMF. It's not clear to me what the > intended architectural direction might be.
I think that's appropriate since it's not clear to the SMF team, either. As I alluded to in my mail to Mr. Shapiro, there seems to be a hirearchy of abstractions here, whereas SMF currently only supports a flat space of the lowest level - individual daemons. I suspect we could allow developers to deliver higher-level virtual services which would represent lower-stability restart-units, but the SMF team hasn't discussed that. In the short term, redirecting users from implementation details to higher-stability feature-specific commands seems like a sweet spot. > More deeply, it seems to me that there are two forces that are in > conflict here. On one side, we want to have task-specific tools to > make administration simpler and more coherent than can be accomplished > with svccfg. On the other side, those tools have underlying > dependencies on bits that we have no choice but to expose via SMF and > thus encourage use from outside the task-specific framework. Ah, but this proposal is about offering a choice about exposure via SMF. Perhaps it should go deeper and not even expose them for reading. (Which is reminiscent of the recent exchange between meem & Stephen Hahn.) > The big problem I see with that (and I had a hallway discussion with > the recently-returned meem yesterday) is with profiles. How is it > that a profile can be constructed and maintained if the contents > actually represent references to internal service implementation > details? Yes, this is a key realization of the Enhanced Profiles project -- the actual properties of each service is the implementation of that service, and really, only feature-specific tools should ever be interpreting them or changing them (e.g., the share(1M) command or the NFS "Visual Panels" plugin). If a developer has decided that it makes sense to expose a raw property to a user, then he should do so because he gets the svccfg interface (and presumably the upcoming auto-generated "Visual Panels" graphical user interfaces) for free. And the semantics of those interfaces could be enhanced by the metainformation supplied via the template mechanisms (see http://opensolaris.org/os/project/vpanels/templates ). In any case, for the most part, the contents of profiles should be considered opaque to the ordinary user. David
