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

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

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/

Reply via email to