Jordan Brown writes:
> > I'll argue that anything that sents the same set of flags to the same
> > state ought to be time-invariant, if it's going to be comprehensible
> > to mere mortals.
> 
> I am not quite sure that I follow your point.  How you get from point A 
> to point B can be quite important.

I agree that the order of operations along the path is important.

I'm saying that I don't think you should end up in a different stable
(long-term) state if the same set of flags are set.  In other words,
this:

        svcadm disable foo/top-one
        svcadm enable foo/a-depends-on-top-one
        svcadm enable foo/b-depends-on-top-one

should result in the same long-term state as:

        svcadm enable foo/a-depends-on-top-one
        svcadm enable foo/b-depends-on-top-one
        svcadm disable foo/top-one

> > At this point, the question I'm asking is whether you should be able
> > to enter "offline" state in both orders or just one.  I think entering
> > it in just one order (failure-like semantics) makes more sense.
> 
> Here's an analogy:
> 
> You can get the system from fully running to powered off in two ways:

I'm not so sure that analogy works too well.  One of the clear
side-effects of losing power is that RAM is cleared out and in-flight
disk transactions are gone.

That's not true of the state of the dependent services after a service
failure.  Those services still get a chance to shut themselves down in
an "orderly" way, if they're still able to do that.

As long as we have to handle the case where a dependency goes away
(and the service has to go into "offline" state), I think we ought to
be consistent about handling that case.

> They both end up at the same point - system is powered off - so they're 
> equivalent, right?  Why do we bother with all of this orderly-shutdown 
> stuff, when we have to handle the powerfail case anyway?

Not the same; all services lose state on the power-off case, not just
the one that failed.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Reply via email to