On Fri, Jul 25, 2008 at 16:34, NAKAHIRA Kazutomo <[EMAIL PROTECTED]> wrote: > Hi, Andrew > > Thank you for your advice. > >> If you don't want non_clone_group1 to be restarted when this happens, >> make the ordering constraint advisory-only by setting adding score="0" >> to the constraint. > I tried this configuration, but non_clone_group1 was restarted > when clone1 resources fail-count was cleared.
you're right - this appears to be broken :( > > I added score="0" setting below: > > <rsc_order id="order_resource1_clone1" from="clone1" action="start" > type="before" to="resource_group1" score="0"/> > > This configuration has some mistakes? looks fine > > >>> And to make matters worse, if clone1 and non_clone_group1 has >>> rsc_colocation constraints, then non_clone_gropu1 resoureces >>> restart brew up automatic failback. >> >> You lost me... can you rephrase? > I'm Sorry, my English skill is not well. > > What I mean is below: > > 1. clone1 resource monitor failed on the nodeA > > 2. All clone1 resources are stopped on the nodeA. > > 3. If clone1 and non_clone_gropu1 has co-location constraint below, > then non_clone_group1 fail-over to nodeB. > > <rsc_colocation id="resource_and_clone" from="non_clone_group1" to="clone1" > score="INFINITY"/> > > 4. Recover clone1 resource on the nodeA using "crm_resource -C" > and "crm_failcount -D" command. > > 5. non_clone_group1 on the nodeB stopped. and then, > clone1 started on the nodeA. > > 6. non_clone_group1 started on the nodeA.(fail-back occurred) > > The operation that I expect is that > non_clone_group1 operates on the nodeB and automatic fail-back > dose not occurred when nodeA is recovered. ok, was the testcase for this in the previous email? > > Andrew Beekhof wrote: >> >> On Wed, Jul 23, 2008 at 04:52, NAKAHIRA Kazutomo >> <[EMAIL PROTECTED]> wrote: >>> >>> Hi, all >>> >>> I trying newer version of lha-2.1(changeset: 12148:e902ad7642fd) >>> and notice that rsc_order constraints behavior between Clone Set >>> and non-clone(active-standby) Resource Group may be changed. >>> >>> In my test environment(2-node active-standby cluster), >>> I setting rsc_order constraints below. >>> >>> <rsc_order id="order_resource1_clone1" from="clone1" >>> action="start" type="before" to="non_clone_group1"/> >>> >>> If clone1(Clone Set ID) resource monitor failed, then >>> all clone1 resources stopped. >>> >>> And non_clone_group1(Resource Group ID) resources do-noting. >>> It is OK. >>> >>> But I recovery clone1 resource failure and clear resource status >>> and reset fail-count(using crm_resource -C and crm_failcount -D), >>> then clone1 resources started and all non_clone_group1 resources >>> restarted. >>> >>> In Heartbeat 2.1.3, non_clone_group1 resoureces are not restarted >>> in the same situation. >> >> Thats a bug in 2.1.3 >> The mandatory part of the ordering constraint was being ignored. >> >> If you don't want non_clone_group1 to be restarted when this happens, >> make the ordering constraint advisory-only by setting adding score="0" >> to the constraint. >> >>> And to make matters worse, if clone1 and non_clone_group1 has >>> rsc_colocation constraints, then non_clone_gropu1 resoureces >>> restart brew up automatic failback. >> >> You lost me... can you rephrase? >> >>> Is it expected behavior? or my configuration has some mistakes? >>> >>> Best Regards, >>> NAKAHIRA Kazutomo >>> >>> -- >>> ---------------------------------------- >>> NAKAHIRA Kazutomo >>> NTT DATA INTELLILINK CORPORATION >>> Open Source Business Unit >>> Software Services Integration Business Division >>> >>> _______________________________________________ >>> Linux-HA mailing list >>> [email protected] >>> http://lists.linux-ha.org/mailman/listinfo/linux-ha >>> See also: http://linux-ha.org/ReportingProblems >>> >> _______________________________________________ >> Linux-HA mailing list >> [email protected] >> http://lists.linux-ha.org/mailman/listinfo/linux-ha >> See also: http://linux-ha.org/ReportingProblems > > > -- > ---------------------------------------- > NAKAHIRA Kazutomo > NTT DATA INTELLILINK CORPORATION > Open Source Business Unit > Software Services Integration Business Division > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
