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.
This doesn't make sense to me: dladm -t should mean muck with the abstractions but do nothing to the saved smf configuration. That's the equivalent of what it means now. Or to make another analogy, it's like running ifconfig without changing /etc/hostname.XXX > * 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). There should be no daemon running for networking instances. i.e. they should be all marked transient since the kernel holds the state. > 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. As I say above that doesn't make sense to me. > > * From a conceptual standpoint, it's unclear to me why it's > unreasonable to model temporary configuration using SMF. I > agree with your point above that not every state machine needs > to be represented by SMF, but here we've already chosen to > model IP interfaces and datalinks using SMF, so it doesn't > strike me as unreasonable to model temporary ones too. You're misunderstanding my argument, then. The SMF state is not for a copy of what is going on in the kernel. It is for the saved state of how the admin wants the machine configured persistently. You will want to have some way of manipulating the underlying abstractions without touching SMF if for no other reason than to implement your per-instance start methods. > From a pragmatic perspective, it would help me to know more of > the use-cases for the IP interface and datalink SMF instances. > Right now, the uses I'm aware of are (a) simplifying boot-up, > (b) providing a convenient high-level interface to the admin > through svcs et al., and (c) allowing NWAM to manage them. > For those cases, I agree that temporary datalinks are either > irrelevant or relatively unimportant. But without a more > complete understanding of how these SMF instances will be used, > it's hard for me to share your conviction. Same as everything else in SMF: we want a standard way for representing saved administrative configuration that can be used to simplify programmatically manipulating it, and applying higher-level services such as role-based access control, snapshot/rollback, auditing, fault management stack connections, and so on. Without SMF, every single system facility has to either re-implement all of that, or not provide them. Looking at dladm and ifconfig today, we have none of those features. If networking is converted to SMF, then we have all of them. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
