On Thu, Jan 17, 2008 at 02:27:28AM +0800, Peter Memishian wrote: > > SMF should not support such temporary instances. SMF is not a replacement > > for every kernel state machine. Creating temporary network mods is the > > mental equivalent of starting a daemon outside of its smf instance -- it > > works, you can do it, etc. but it is not reflects in your svcs output. > > This is an interesting analogy and it makes some sense to me. However: > > * The actions needed to start a daemon are quite different from > those needed to have SMF start a daemon, but here the only > distinction is whether the "-t" flag is passed to dladm. > > Further, the semantics seem possibly surprising: if "-t" is not > used, then the dladm changes are immediately reflected in the > SMF configuration (along with the SMF configuration tied to > subsequent boots), so one might intuit that using "-t" will > still result in immediate changes to SMF configuration -- and > be surprised to discover no SMF changes were made at all.
I think an important distinction here is configuration vs. state. "-t" changes do not create new *configuration*; but they do create new state. Most of what's stored in the repository for links and interfaces is configuration, and we've tried to minimize the amount of state that is represented there. So given your example, if you think of what you're looking at in the repository as primarily configuration data, it shouldn't be surprising that "-t" changes don't appear there: those changes are not creating persistent configuration, by definition. That said, some amount of state clearly exists, with the service state being the most obvious example. We do intend for that to communicate information about the state of the link or interface. I think this is why this is such a difficult question! The repository is serving many different purposes here, and it's hard to fit all the pieces together. > * Following the daemon example, SMF will restart assassinated > daemons that are under SMF control to maintain the integrity > of the service. By analogy, that might mean that if one > "delete-vlan -t"'s a link that has an SMF service instance > associated with it, SMF would recreate the VLAN, which will > probably surprise the sysadmin (then again, the auto-restart > of pkill'd daemons surprised many too). > > As I undertand Max's current prototype, he's wired the delete > -t functionality to temporarily disable the SMF service > instance, which seems a reasonable option. However, having > delete -t tied in with SMF and create -t not tied in seems > asymmetric and (to me, at least) illustrates the awkwardness > of handling -t. I agree, this is definitely awkward. We could have temporarily enabled instances as well; but I would rather see those completely go away, than to linger in the disabled state. Going back to Mike's general principle: they aren't things that will be managed within the smf framework; no smf restarter will enable them. I think the enhanced smf profiles project[1] might offer us a more suitable model. It introduces precedence levels, which allow changes to be layered on top of each other, allowing overrides of properties without destroying the underlying settings. In particular, there will be a system-override precedence level, designed specifically for the purpose of publishing status. Data at this level is intentionally non-persistent. We need to do more investigation, but I think this might be a good way to model temporary links and interfaces. -renee [1] http://opensolaris.org/os/project/smf-profiles/Design/
