Sebastien Roy wrote: > Alan Maguire wrote: >> right, but consider the consequences of representing >> temporary entities as SMF instances - the semantics >> of enabling an instance imply that the enable action >> is persistent, i.e. the service instance will be enabled >> at next boot also. > > svcadm doesn't seem to have such stringent semantics when enabling a > service instance with the "-t" option. > but once an instance exists in the repository, whether our intent is for it to be temporary or not, it'll be legal to carry out the various svcadm options on it, including persistent enable. in the case of a temporary instance, what would that mean? (in other words, running "dladm create-foo -t" followed by "svcadm enable" without the "-t" flag). to me it would imply that the instance should be persisted rather than removed at next boot (since running "svcadm enable/disable" without the -t flag obliterates prior temporary state specification). if we could distinguish such persistent enabling/disabling events, and respond to them by marking the instance as persistent across reboot in such a way that dlmgmgtd knows not to remove it, that might be a reasonable way to go. but this conflates the concepts of instance existence and instance state somewhat, since temporarily enabling an instance means it'll still be there on next boot, merely disabled.
perhaps we don't need all this complexity, but my worry is that this concept of temporary instances doesn't exist in SMF at present, and once an instance exists in the repository, the service tools should be able to interact with it in a way that is consistent with existing conventions. i can't think of an easy way to do this. perhaps the SMF team might have some suggestions here. >> if we support an instance representation >> for temporary entities (which can be manipulated by >> svcadm), my fear is that it will set expectations in this >> direction. > > But if temporary data-links are not represented as SMF instances, how > will the rest of the NWAM stack (IP and above) cope with these? > Doesn't the entire design hinge on IP instances depending on data-link > instances? > the configuration managed/created by NWAM via the GUI/nwamcfg will be persistent. we have to catch certain events such as interfaces acquiring addresses (in order to evaluate profile predicates), and sometimes these will occur for non-persistent links/interfaces that are not managed directly by NWAM, but we wouldn't require the SMF representation of those entities to do this. alan
