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.
I do think that temporary instances are viable, and may even be necessary for some tasks. (I continue to worry about things that admins and even some system deployers used to just dump into /etc/rc?.d during boot to do startup-order dependent tasks just once. It should be easy to do that under SMF too, and a manifest and non-temporary service is pretty heavyweight. It dovetails with the pkg discussions about postinstall actions, though, so I'd rather not half-explore that particular problem in this thread.) I agree with Mike there are some things to worry about as far as the administrative model for temporary instances. (And dependencies.) It's certainly not on the immediate roadmap, so I'm not sure whether any of the above is helpful. As far as the temporary creation goes, the other piece of design to consider is whether it's a requirement that somoene can to go from temporary to permanent without re-specifying the command-line configuration. That is, "I tried this change, it worked out, and now I want to make it permanent". It seems the difference is in context: is someone doing this to try the config out before committing to deploying it, just playing around with the system, or doing emergency reconfiguration things. Finally, I'll stray from architecture and into current implementation and will note that you could create pseudo-temporary instances today. Using interactive svccfg, I can do this: add foobar select foobar add default select default addpg general framework P (note the P, which means non-persistent) setprop general/enabled = boolean: true Obviously, on reboot the "foobar:default" service will remain, but we leave things alone which don't have a general/enabled property. (I guess svcs doesn't currently leave instances alone which don't have a general/enabled property, but the rest of SMF does, so we could probably change that. David will probably catch me and note that profiles is considering perhaps using a different barometer for a 'complete' service instance, but the concept is the same here.) It isn't clear that's better than your second option, though, which is the one that I'd lean towards on first glance. liane
