Hi,
I tried but it does not work :
crm_resource -r resname -p target-role -v started
because it adds a target-role=started as params
whereis I already have a meta target-role=Stopped
so resource does not start.
So I tried :
crm_resource -r resname -m -p target-role -v started
then resource starts successfully.
But with a loop:
for i in {1..20}; do echo resname$i ; crm_resource -r resname$i -m -p
target-role -v started; done
The first one is started immediately, and the 19th other ones are
started ~20s after the first one
but all in one salvo.
So it seems to be quite the same behavior as successive "crm resource
start resname$i" commands.
First command is taken in account immediately, then there is a delay
perhaps before pooling eventuals
other crm commands, but as during this delay , my loop has already sent
19 commands, these are
taken in account in one shot when the new polling occurs.
Meaning, that manually, if you wait that the expected result of your crm
command is displayed on crm_mon,
before sending the second one etc. there is always this 10 to 20s
latency between each commands.
(Same behavior inside scripts if the script waits for the command to be
really completed by testing ...)
Hope my description is clear enough ...
Thanks
Alain
Dejan Muhamedagic a e'crit:
> On Thu, Mar 10, 2011 at 03:18:30PM +0100, Lars Ellenberg wrote:
>
>> On Thu, Mar 10, 2011 at 02:49:01PM +0100, Dejan Muhamedagic wrote:
>>
>>> Hi,
>>>
>>> On Wed, Mar 09, 2011 at 10:02:01AM +0100, Alain.Moulle wrote:
>>>
>>>> Hi Dejan
>>>>
>>>> I tried to reproduce the latency pb between commands, bt with only
>>>> some Dummy resources :
>>>> Resource Group: group-dummy1
>>>> resname1 (ocf::pacemaker:Dummy): Started chili2
>>>> resname2 (ocf::pacemaker:Dummy): Started chili2
>>>> resname3 (ocf::pacemaker:Dummy): Started chili2
>>>> resname4 (ocf::pacemaker:Dummy): Started chili2
>>>> Resource Group: group-dummy2
>>>> resname5 (ocf::pacemaker:Dummy): Started chili2
>>>> resname6 (ocf::pacemaker:Dummy): Started chili2
>>>>
>>>>
>>>> and in fact when using crm to start /stop for example :
>>>> crm resource start group-dummy1
>>>> (this one is instantaneously taken in account)
>>>> then just after the first one, I do : crm resource start group-dummy2
>>>> there is a latency of 10 to 14 s before the resource
>>>> is displayed "started" via crm_mon
>>>>
>>> Normally, pacemaker reacts as fast as it can. The explanation
>>> must be in the logs.
>>>
>> Instead of "crm resource x start/stop", try
>> crm_resource -r x -p target_role -v started
>> crm_resource -r x -p target_role -v stopped
>>
>> iirc, crm sends a cib replace, which causes re-election of the DC,
>> which may or may not take some time.
>>
>
> Hmm, that should've been fixed, sometimes last year. I think
> that both 1.0.10 and 1.1.5 contain the fix.
>
>
>> crm_resource will send a cib diff update, no re-election will be done,
>> and it just goes directly -> policy engine -> transition engine.
>>
>> May or may not help ;-)
>>
>
> Yes, it's worth a try.
>
> Thanks,
>
> Dejan
>
>
>> --
>> : Lars Ellenberg
>> : LINBIT | Your Way to High Availability
>> : DRBD/HA support and consulting http://www.linbit.com
>> _______________________________________________
>> 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
>
>
>
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
