> 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.
* 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).
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.
* 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.
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.
--
meem
