[Pacemaker] Migration atomicity

[Andrew Beekhof]

On Thu, Mar 15, 2012 at 3:22 PM, Vladislav Bogdanov
<bubble at hoster-ok.com> 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).

It doesn't matter how fast it is, we will wait for it to finish.
We don't guarantee the _from will get executed after that though.

>
> And I do not see a roll-back (what can it mean?), I just see that
> migration is broken in the middle.
>
> Best,
> Vladislav
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org