2010/3/9 <renayama19661...@ybb.ne.jp>: > Hi Andrew, > >> This is normal for constraints with scores < INFINITY. >> Anything < INFINITY is "preferable but not mandatory" > > Sorry.... > The method of my question was bad. > > As of STEP9, is the setting that a resource of UMgroup01 does not start > possible?
Only if you change: <rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01" with-rsc="clnPingd" score="1000"/> to <rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01" with-rsc="clnPingd" score="INFINITY"/> > > I do not perform the INFINITY setting in cib.xml. > As of STEP9, I do not understand causes to become INIFINITY well. > > Best Regards, > Hideo Yamauchi. > > > --- Andrew Beekhof <and...@beekhof.net> wrote: > >> 2010/3/5 <renayama19661...@ybb.ne.jp>: >> > Hi All, >> > >> > We test complicated colocation appointment. >> > >> > We did resource appointment to start by limitation of colocation together. >> > >> > But, the resource that set limitation starts when the resource that we >> > appointed does not >> start in a >> > certain procedure. >> > >> > We did the following appointment. >> > >> > <rsc_colocation id="rsc_colocation01-1" rsc="UMgroup01" >> > with-rsc="clnPingd" >> score="1000"/> >> > >> > When clnPingd did not start, we met with the phenomenon that UMgroup01 >> > started. >> >> This is normal for constraints with scores < INFINITY. >> Anything < INFINITY is "preferable but not mandatory" >> >> _______________________________________________ >> Pacemaker mailing list >> Pacemaker@oss.clusterlabs.org >> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >> > > > > _______________________________________________ > Pacemaker mailing list > Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > _______________________________________________ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
