Quoth Mike Shapiro on Sun, Jan 20, 2008 at 11:51:12PM -0800: > 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.
I don't understand how temporary instances replaces the kernel's link state machine. Can you explain please? > > 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 The current / post-boot behavior split embodied by daemon launching / init scripts and ifconfig / hostname files is, as far as I can tell, born of implementation convenience and is something that SMF is trying to abstract away by default. (That is, by default administrative behavioral desires are enacted immediately and persist across reboot. If the administrator truly desires behavior to change at reboot, then that can be specified explicitly.) Otherwise, why does svcadm enable start the daemon immediately? Why did we implement svcadm enable -t? Why didn't we just tell each developer to document that the way to initiate behavior which will not survive reboot is by launching the daemon manually? dladm -t creating instances may not make sense to you, but I think the criterion should be whether it will make sense to users. Since we've apparently already decided that the SMF tools are a valid interface to link administration (since instance names must correspond to link names), it seems to me that this decision (from a user experience perspective, at least) boils down to whether the SMF interface is as complete as the official interface (dladm). I think most administrators will infer this (based primarily on the link name correspondence), and would find the "it's not there because it doesn't impact reboot" logic surprising. To do otherwise, it seems to me, should require substantial supportability or implementation cost arguments. > > * 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. SMF state (apart from configuration) is behavioral status. If the kernel (or any other part of the system) is exhibiting behavior which is contradicted by the status published by SMF, then that's a bug. > 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. Are you saying that all network interfaces must be documented for the administrator, even if the networking team only introduces them to implement the administrative interface? David
