James Carlson wrote:
> It's not an orderly shutdown if you request to have a service with
> hard dependencies shut down and you don't also ask to have those
> dependencies shut down as well, is it?

It depends on whether you consider it obvious that they are implicitly 
shut down.  I'll grant that that's not a foregone conclusion, and 
perhaps your "-f" / "-r" answer is a better one, to make the 
administrator intent explicit.

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

> So, run the scenario in the forwards order: if you enable those
> dependent services without ever having enabled the required dependency
> enabled, then the dependent services end up in "offline" state without
> ever having run in any order.

Yes.

> I think that if we allow a dependency in the middle of the tree to be
> yanked out arbitrarily, we should end up in the same state as if we'd
> enabled everything but skipped over that one entity.  That means
> getting them into "offline" state in either case.

Yes.  (But there is a question as to *how* you get there.)

> That's also the same as if we had failed this dependency, and we thus
> had to tear everything down after the fact -- basically ignoring the
> reverse-order "requirement."

Yes.

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

1)  Shut down all of the services in an orderly fashion, and then remove 
power.

2)  Remove power.

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?

> It even allows for more obvious testing scenarios by just disabling a
> required service to make sure that failure handling "works" (whatever
> that means ;-}).

Now, indeed, there's a lot to be said for designing a system so that the 
way that you turn it off is simply to remove power, but for a bunch of 
reasons we don't usually do that.


Reply via email to