Alan Maguire wrote: > 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. > Yes, it is quite confusing if you take an persistent action based on a temporary configuration. With representing temporary configuration via smf instances, we seem to add one more way to confuse our customers :(.
So, if we really don't want to create temporary instances, I think we also should avoiding storing temporary configuration data into smf instances, in order to make the restriction less confusing - smf instances are all persistent and only stores persistent configuration data. Current implementation of dlmgmtd is doing the same thing. Only persistent data go to /etc/dladm/datalink.conf. Non-persistent data is stored in kernel (non-persistent name-linkid mappings are stored in a temporary file). Max > 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 > > _________________________________ > clearview-discuss mailing list > clearview-discuss at opensolaris.org >
