Liane Praza writes: > 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.)
OK; that seems reasonable. My question was pretty narrow because I was just interested in how it affected *me.* > 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. The administrative model seems fairly obvious to me -- 'svcs' shows the same things as for other instances, but may be enhanced to show that an instance is merely temporary. (For what it's worth, it'd be really nice to show whether a service has been enabled with "svcadm enable -t" versus "enable" -- as far as I know, that's an administrative hole today.) > 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. Yes. Having a "save configuration" button would be nice, and seems pretty obvious. It's already a problem. I can do "enable -t" on a bunch of services, but then forget which ones I've enabled and have no way of saying "make my current state the next reboot state." > 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 That's pretty much the first option I mentioned -- create a permanent instance and then enable it temporarily. > 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. OK; thanks ... that was the "add temporary instances to SMF" option. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
