Alan Maguire wrote: > Peter Memishian wrote: >> > Or, for now, we choose not to create any smf instance for temporary >> > configuration. We only represent persistent configuration via smf >> > instances. Thus, we don't have to worry about removing them during >> next >> > reboot. And we'll add temporary configuration support later when >> we have >> > some support from smf framework to handle such temporary instance. >> But, >> > the questions here are that: >> > Is this an acceptable way to represent networking configuration? >> > Do we have any plan to add temporary instance support in smf >> framework? >> >> FWIW, as I stated at the meeting, I fear this approach *is* unacceptable >> in the long-term, because it means that the administrator (or tools) can >> no longer rely on SMF to provide the current state of these system >> services. The result is that the SMF representation of IP interfaces >> and >> datalinks becomes only meaningful as an implementation convenience for >> tools such as NWAM, which was one of the things that mws was vehemently >> against in the original Clearview UV SMF proposal. >> >> > my understanding of the current SMF model is that service instances > represent configuration intent (mostly this is persistent configuration > intent, but temporary property groups which disappear on reboot > can figure also). instance state informs if this intent was applied > (online/offline/disabled) and if it was applied (i.e. the instance was > enabled and its dependencies were satisfied), the state can also > represent the result of that application (maintenance/degraded/online). > assuming i have this right, my concern about introducing temporary > instances is how these will sit with the existing SMF administrative > model (there is already a concept of temporary state change, > but not of temporary existence as far as i know). for example, if an > instance is temporary, should administrator-driven changes which > would be normally assumed to lead to persistent state changes (e.g > "svcadm enable datalink:foo") change the status of the instance > too (from nonpersistent to persistent), since they implicitly assume > persistence of the instance in question? Yes, this has to be defined clearly in smf framework before we create temporary smf instances in our system.
I think that one big benefit we get from smf framework is we have a way to represent the configuration of the system and tools to interact w/ that configuration *dynamically*. So, once we represent networking environment as smf instances, we, then, get the above benefit from smf framework. No matter how temporary an datalink/interface is, it is part of the current configuration applied in the system. So, it should be able to be configured by smf tools dynamically. But, if we don't represent that part of configuration as smf instances, it's going to be hard for them to be configured by smf tools. And w/ part of the configuration (persistent part) that can be configured by smf tools, we're likely to confuse sysadmins. And yes, that is our long term goal. If we cannot find a good way to represent temporary part of configuration, I agree to hide them for now. Otherwise, we'll probably confuse sysadmins more... Max > > i wonder if there are concepts in enhanced SMF profiles (perhaps > a mutable, temporary profile within which such instances could > live) that could help here perhaps? could temporary instances > live in a temporary enhanced profile that disappears on reboot in the > same way that temporary property groups do? there seems to > be a persistence property in such profiles in the latest design. > > alan
