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". > 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? > 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. David
