David Bustos writes: > Quoth James Carlson on Wed, Mar 19, 2008 at 10:53:01AM -0400: > > Given a "temporary instance" design that's implemented as a real > > instance, but with the service disabled in the repository, what > > happens when the user does this to a regular (non-temporary) instance? > > > > svcadm disable svc:/network/bridge:foo > > svcadm enable -t svc:/network/bridge:foo > > > > Does that turn it into a temporary, causing it to lose its moorings > > unexpectedly? > > What do you mean by "turn it into a temporary"? Those commands > temporarily enable the service. I presume that you intend to interpret > temporarily enabled services as "temporary services"? I don't see an > inherent problem with that right off, and I don't know what you mean by > "losing its moorings unexpectedly".
Note the "given:" this is specifically a reference to a work-around for the current lack of temporary instance capability. That work-around involves creating a disabled instance in the repository, configuring it as desired, then doing a temporary enable on the instance. The weird case I'm pointing out is that if I actually do that, then odd things can happen if the user tries to enable and disable services. Specifically, if we have a regular (non-temporary) instance, and the user does a regular disable (against the non-volatile repository), and then does a temporary enable, the final system state is _indistinguishable_ from having a temporary instance. It's as though the non-temporary instance suddenly became temporary -- with all that entails. If we had a boot-time clean-up service (as some have suggested) for these things, then the configuration would be wiped away. > > What happens in the reverse case (or is being able to > > sediment a temporary just an unexpected "feature?")? > > Do you mean permanently enabling a temporarily disabled service? Well > yes, if you choose to interpret temporarily enabled services as > temporary services, then the user can do that. Is that a problem? No, I don't mean that. Again, using the work-around described above, if someone creates a temporary service but then does a temporary disable and a permanent enable -- perhaps by mistake -- the result is that the "temporary" instance suddenly becomes permanant. > > And then come the questions about why I can configure an instance that > > is itself temporary, but I cannot set temporary changes to parameters > > on a non-temporary instance -- because I can only have one property > > group with a given name, and a group can only be temporary or > > permanent, not both. Isn't it just as likely that I'll want to do > > that? > > Yes, that's something that the original designers either didn't > anticipate or didn't have time to design, so we had to kludge something > for temporary enable and disable. (Namely, general_ovr.) The Enhanced > SMF Profiles project should introduce the generality you expect. OK; thanks. -- 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
