Bug #7267

Updated by Andrew Stormont over 4 years ago

In terms of res order optional dependencies should behave like normal dependencies (when they're online and the restart_on attribute is set to "restart" or "refresh").    In reality this is not the case.    Restarting an optional dependency usually results in the dependent being restarted first and the optional dependency being restarted after.    Clearly this is broken. 

 Part of the problem is that optional_all dependencies are bypassed when marking dependents to do down/checking that they've gone down.    It also doesn't help that the dependency code is extremely naive and has almost no handling for instances that are transitioning (GV_TOOFFLINE is handled, but that's about it). 

 In short, the dependency handling code for optional_all dependencies is so loose that they are nearly always considered satisfied.    Because of this the start/restart order is completely unpredictable.    The other dependency group types suffer from similar problems though to a much lesser extend (except require_any dependencies, which are always satisfied).