hi meem Peter Memishian wrote: > > > But I personally think that temporary datalinks should also be > > > represented as SMF instances, as they do provide datalink services. > > > > > yeah, i can see that there's a reasonable argument to do this. i think > > the key question is whether we expect the SMF representation > > to be complete regarding what is configured on the system, > > versus being complete about what is _persistently_ configured > > on the system. the latter is probably less intuitive to administrators, > > but i don't know that that is such a big problem - my assumption > > is they'll be using dladm to query link status rather than > > "svcs datalink/*". the problem i see with exhaustively > > representing temporary configuration is having to undo the > > temporary portions of the configuration explicitly (i.e. the > > instances that were created via temporary commands) on > > reboot. > > I thought SMF already had a way to mark e.g. property groups as being > temporary? Is that functionality insufficient? > > temporary property groups will work fine (they disappear on reboot) but the problem is they need to be stored in instances, which are always persistent across reboot. this is a problem because such temporary instances would need to be torn down explicitly on reboot as a result. while this is doable, it does stray somewhat from the SMF model which is geared towards storing configuration intent, and i'm concerned about the knock-on effects of having SMF representations for such temporary entities, e.g. the GUI would likely then have to determine the nature of the object represented (temporary or persistent), and likely not display such temporary instances.
since it appears that the temporary information we need to store maps to data that dlmgmtd needs to retain (but not across reboot) for restart purposes - i.e. the linkid-linkname mappings - my suggestion is to store that data locally within the datalink-management instance in a temporary property group. the motivation for this distinction is that the methods for these persistent instances could potentially simply instantiate the object they represent temporarily, e.g. in the case of an aggregation instance start method, we'd have: "dladm create-aggr -t ...". the benefit of this approach is that the existence of the aggregation is predicated on the state of the instance, as opposed to having to modify "dladm up-aggr" say to correlate configuration data with instance state (i.e. the only persistent aggregations that are created on boot are those that have instances that are enabled). > FWIW, I agree with Cathy that temporary datalinks should be represented as > SMF instances, for the same reason that temporarily enabling a service > still causes that service to show up in `svcs'. > > 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. 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. alan
