Mike Shapiro wrote: > On Tue, Jan 22, 2008 at 01:24:34PM +0800, Peter Memishian wrote: > >> > In terms of your question, I think all that is required here is decide on >> > some reasonable semantics for existing service instances. The one that >> > comes to my mind is temporary disable (equivalent of svcadm disable -t). >> > i.e. if I use dladm -t to modify something and an instance exists in SMF >> > for that and it is enabled, then dladm -t temporarily disables it. >> > The semantics of temporary disable already means that it will return >> > on next reboot, so that seems to fit. Anyway, think it through. >> >> This approach is what Max has already done, as per my earlier email: >> >> 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. >> >> ... to which you responded "As I say above that doesn't make sense to me." >> > > Right. As in, the notion that this asymmetry is somehow an issue doesn't > make sense to me. -t means do stuff outside of smf. Max's idea is just > trying to be friendly there in a way that *is* consistent with what is > being presented. I see no problem there. > > Personally, I don't even find that to be necessary -- I see no issue with > having svcs show the smf state yet have tools to mess with the underlying > thing. Because as a reminder, administrators don't ever need to run -t -- > it's there for our use in building the method scripts or for development/ > debugging/testing. (We have many other similar such options in our system > today in various utilities.) > Will temporarily removal of a datalink configuration be involved in DR process? Say, if we have a vlan on top of bge0. If we DR out that bge0 card, will that vlan be temporarily deleted?
Max > But I also don't object to Max's approach of delete -t => disable -t. > As I said, this is extending the boundaries of what has been done, so > decide what seems reasonable and get input from others (as you're doing). > > As we evolve the SMF mechanism to contain new abstractions, there will be > a natural evolution of the framework itself and how to use it. That is > all goodness, because it contributes to the overall leverage point. > > -Mike > >
