[Pacemaker] Migration atomicity

Vladislav Bogdanov bubble at hoster-ok.com
Thu Mar 15 04:05:34 EDT 2012


15.03.2012 10:55, Andreas Kurz wrote:
> On 03/15/2012 05:22 AM, Vladislav Bogdanov wrote:
>> 15.03.2012 01:49, Andreas Kurz wrote:
>>> On 03/14/2012 08:40 AM, Vladislav Bogdanov wrote:
>>>> Hi,
>>>>
>>>> I'm observing a little bit unintuitive behavior of migration logic when
>>>> transition is aborted (due to CIB change) in the middle of the resource
>>>> migration.
>>>>
>>>> That is:
>>>> 1. nodea: migrate_to nodeb
>>>> 2. transition abort
>>>> 3. nodeb: stop
>>>> 4. nodea: migrate_to nodec
>>>> 5. nodec: migrate_from nodea
>>>> (note: no stop on nodea)
>>>>
>>>> While I expect migration operation pair to be "more atomic":
>>>> 1. nodea: migrate_to nodeb
>>>> 2. transition abort
>>>> 3. nodeb: migrate_from nodea
>>>> 4. nodea: stop
>>>> 5. nodeb: migrate_to nodec
>>>> 6. nodec: migrate_from nodeb
>>>> 7. nodeb: stop
>>>>
>>>> Is the current behavior intended?
>>>
>>> You mean that a migration is rolled-back due to a transition abort --
>>> depending on its progress? I think that is the defined (and intended)
>>> behavior since quite a long time ... maybe Andrew likes to comment on that?
>>
>> RA is very fast, it mostly operates on a pseudo-resource, so migrate_to
>> should be finished somewhere near transition abort (which is caused by
>> another resource which starts in the same time and modifies CIB).
>>
>> And I do not see a roll-back (what can it mean?), I just see that
>> migration is broken in the middle.
> 
> Roll back like: migrating a group with several resource, some are
> already migrated -- transition abort -- already migrated resources are
> migrated back or to another node.
> 

Ah, you're talking about groups...
That is not my case, I have that resource "stand-alone".
I just see that migration of that resource is not finished (usual
migrate_from/stop is not called).

Vladislav





More information about the Pacemaker mailing list