9.3.4. Resource Migration
Some resources, such as Xen virtual guests, are able to move to another location without loss of state. We call this resource migration; this is different from the normal practice of stopping the resource on the first machine and starting it elsewhere.
Not all resources are able to migrate, see the Migration Checklist below, and those that can, won’t do so in all situations. Conceptually there are two requirements from which the other prerequisites follow:
The cluster is able to accommodate both push and pull migration models by requiring the resource agent to support two new actions: migrate_to (performed on the current location) and migrate_from (performed on the destination).
In push migration, the process on the current location transfers the resource to the new location where is it later activated. In this scenario, most of the work would be done in the migrate_to action and, if anything, the activation would occur during migrate_from.
Conversely for pull, the migrate_to action is practically empty and migrate_from does most of the work, extracting the relevant resource state from the old location and activating it.
There is no wrong or right way to implement migration for your service, as long as it works.
9.3.4.1. Migration Checklist
The resource may not be a clone.
The resource must use an OCF style agent.
The resource must not be in a failed or degraded state.
The resource must not, directly or indirectly, depend on any primitive or group resources.
The resource must support two new actions: migrate_to and migrate_from, and advertise them in its metadata.
The resource must have the allow-migrate meta-attribute set to true (which is not the default).
If the resource depends on a clone, and at the time the resource needs to be move, the clone has instances that are stopping and instances that are starting, then the resource will be moved in the traditional manner. The Policy Engine is not yet able to model this situation correctly and so takes the safe (yet less optimal) path.
