Jordan Brown writes: > James Carlson wrote: > > I'm no fan of the "must dial 1 first" school of interface design, but > > I'm not sure that having failure into offline mode occur in two > > different orders (reverse order if done by administrative action, > > forward order if done by actual service failure) is a good thing. > > Yeah, but... they *are* two different cases. > > One is an orderly shutdown. > > The other is recovery from a failure.
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? 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. 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. 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. 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." 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. It even allows for more obvious testing scenarios by just disabling a required service to make sure that failure handling "works" (whatever that means ;-}). > However, we're not talking about the failure case here - we're talking > about an orderly shutdown due to administrative action. ... an administrative action that arguably puts us into a failure case: missing required service. -- 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
