CC'ing nwam-discuss for broader audience Renee Danson Sommerfeld wrote: > As I mentioned in my comments on this bug > (http://defect.opensolaris.org/bz/show_bug.cgi?id=11082), I'm > concerned that the enable-svcs and disable-svcs properties are > likely to cause confusion and inconsistent behavior for people > who try to use them. We don't track the state of the service > prior to activation of the location, so we don't know how to > restore that state when the location is deactivated. > > Furthermore, users can get really similar functionality by > creating ENMs that are dependent on the location. > > So we have a feature that's both somewhat redundant, and also > difficult to implement in a way that will result in consistent, > predictable behavior. That's not a good combination. > The portion that's missing from the ENM is the equivalent of "svcs-disable". "svcs-enable" can be reworked by having an ENM for each service and the ENM having a conditional activation on the location being active. However, the services that need to be disabled when a location is active is not straightforward. Users will have to create script(s) with "svcadm disable" and create ENM(s) for it(them). Not a total loss, so I am ok with removing the two "svcs-enable" and "svcs-disable" properties.
> I also think that in the future, as locations become more > smf-connected, adding this functionality, and making it work > well, will be much easier. > By the way, ENMs also have this problem. If a service is already active before an ENM containing that service is enabled, then that service is disabled when the ENM is disabled. I am getting confused now and am wondering if we are talking about removing the "fmri" property from ENM also (along with the location properties). Anurag
