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?
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
