[ClusterLabs] Advisory order for cluster-managed resources

[Sam Gardner]

"In short, I'd recommend separate constraints :) e.g. start rscA then
promote rscB, promote rscB then start rscC."

I've fiddled around with my code and gotten it to do this.

Just out of curiosity, is there an upper limit on the number of individual constraints that we can put in place?

10 or 15 resources colocated on the same node, starting up in a consistent order will require (at least) 2x the number of constraints in this scheme - it seemed to me that sets would simplify things but perhaps not.


-- 
Sam Gardner
Trustwave | SMART SECURITY ON DEMAND








On 4/3/18, 11:14 AM, "Users on behalf of Ken Gaillot" <users-bounces at clusterlabs.org on behalf of kgaillot at redhat.com> wrote:

>On Mon, 2018-04-02 at 18:47 +0000, Sam Gardner wrote:
>> Is there any way that I can order the startup of resources A, B, C in
>> that order such that if B fails to start for some reason, A and C
>> will still start, but the order of operations will always be start A,
>> start B, start C?
>> 
>> I've tried setting it like this:
>> set rscA rscB.master rscC action=start require-all=false setoptions
>> kind=Optional symmetrical=false
>
>Sets are always confusing IMO. Hopefully one of the pcs developers can
>chime in to clarify some of this ...
>
>I'm not familiar with the rscB.master syntax to specify a role.
>
>action=start with symmetrical=false means that the order would be
>respected when starting, but there would be no order required when
>stopping. Since you're looking to affect only the master role, this is
>probably insufficient, since you probably want to order the *promote*
>of rscB before the start of rscC (start would only ensure slave role).
>
>require-all=false has no effect when sequential=true, which it is by
>default, and it would only affect the ordering between multiple sets,
>not the ordering within a single set.
>
>In short, I'd recommend separate constraints :) e.g. start rscA then
>promote rscB, promote rscB then start rscC.
>
>One thing to keep in mind: optional ordering constraints have an
>effect only if all the actions are occurring in the same transition. In
>other words, with an optional constraint, C *can* start before B, if B
>doesn't happen to be starting at the moment -- e.g. if B also happens
>to be ordered after resource X which hasn't started yet, C can go ahead
>and start, since B is waiting on X. Another example is if B is stopped
>because it has failed too many times, C can still start.
>
>> 
>> Where rscB.master is the Master half of a Master/Slave resource, but
>> if rscB.master fails to come up then rscC also won't start.
>> 
>> I want this to be a stable order so that I know the order in which
>> the resources start up - I can do it with separate constraints but it
>> seems like an order set is a useful shortcut here.
>> -- 
>> Sam Gardner   
>> Trustwave | SMART SECURITY ON DEMAND
>-- 
>Ken Gaillot <kgaillot at redhat.com>
>_______________________________________________
>Users mailing list: Users at clusterlabs.org
>https://scanmail.trustwave.com/?c=4062&d=-qjD2gW59ClGT9a-yPYXaZIcFimXNtkCNaymIIetLw&s=5&u=https%3a%2f%2flists%2eclusterlabs%2eorg%2fmailman%2flistinfo%2fusers
>
>Project Home: http://scanmail.trustwave.com/?c=4062&d=-qjD2gW59ClGT9a-yPYXaZIcFimXNtkCNfuiII79cw&s=5&u=http%3a%2f%2fwww%2eclusterlabs%2eorg
>Getting started: http://scanmail.trustwave.com/?c=4062&d=-qjD2gW59ClGT9a-yPYXaZIcFimXNtkCNfj3KdL-Jg&s=5&u=http%3a%2f%2fwww%2eclusterlabs%2eorg%2fdoc%2fCluster%5ffrom%5fScratch%2epdf
>Bugs: http://scanmail.trustwave.com/?c=4062&d=-qjD2gW59ClGT9a-yPYXaZIcFimXNtkCNfqnJ4b5cg&s=5&u=http%3a%2f%2fbugs%2eclusterlabs%2eorg