Mike Shapiro wrote: > 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. > Yes, if we compare "ifconfig + /etc/hostname.xxx" with "dladm -t + smf instances", it seems obvious that we should completely ignore changes done by 'dladm -t' and keep smf instance intact. But, I'm not sure if that comparison is fully valid... :-\
The problem I see here is that saving persistent configuration in a plain file is somewhat different than saving it in an smf instance. A plain file can save the configuration, no more, no less. You won't be able to tell if that configuration has been applied, or not, by only checking the file containing the configuration. So, no matter how many times you run ifconfig, there is no point to modify /etc/hostname.xxx since that file does not contain any information needs modifying. But, we have a 'state' (online, offline, etc...) associated w/ each smf instance for sysadmin to check any time he wants. Thus, we actually keep more information in smf instance besides the configuration itself. I'm wondering what is the best way to handle these extra information (comparing w/ a plain file database)...for example, if the instance is 'online', should we view it as "the configuration has ever been successfully applied, but whether it is still there is unknown"? Max >> * 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 > >
