On Fri, Mar 07, 2008 at 02:30:59PM -0500, James Carlson wrote: > Nicolas Williams writes: > > So, representing some service configuration and running state in SMF is > > extremely attractive because of dependency management, if nothing else. > > True, but we were at that point discussing the configuration bits. > > > In this case I think the best thing to do is to use instances and leave > > the turds on reboot disabled (perhaps a service to delete what-should- > > have-been-temporary-instances would help, and we can get rid of it later > > when temporary interfaces appear). > > That was part of the basis of my question: will temporary instances > _ever_ appear in SMF, or are they just a Bad Idea in general? > > Mike's answer, if I understand it correctly, was not just that there's > another way to do this (single instance, multiple properties), but > that this way supports temporaries just fine, and doesn't require SMF > changes. > > I can actually go either way, but if I go the way you're suggesting > then I really *do* need to know whether the SMF community thinks that > temporary instances are viable and somewhere on the extended road map > for the system. If they're not, then I really can't see my way clear > to creating a nasty little kludge that ends up living forever. At > least not on purpose. > > Thus my original question.
The reason I mentioned property groups is because, not understanding the details of your service, I was wondering if maybe pg representation was more appropriate. This would solve your problem since smf already supports non-persistent property groups. As for non-persistent instances, I'm not theologically opposed to it, but some thought has to be put into how these get represented, if at all, to the administrator. e.g. can svcs see them? etc. -Mike -- Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/
