[ClusterLabs] Antw: Re: Live Guest Migration timeouts for VirtualDomain resources

Ken Gaillot kgaillot at redhat.com
Thu Jan 19 10:24:48 EST 2017

On 01/19/2017 01:36 AM, Ulrich Windl wrote:
>>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 18.01.2017 um 16:32 in Nachricht
> <4b02d3fa-4693-473b-8bed-dc98f9e3f3f3 at redhat.com>:
>> On 01/17/2017 04:45 PM, Scott Greenlese wrote:
>>> Ken and Co,
>>> Thanks for the useful information.
> [...]
>>> Is this internally coded within the class=ocf provider=heartbeat
>>> type=VirtualDomain resource agent?
>> Aha, I just realized what the issue is: the operation name is
>> migrate_to, not migrate-to.
>> For technical reasons, pacemaker can't validate operation names (at the
>> time that the configuration is edited, it does not necessarily have
>> access to the agent metadata).
> BUT the set of operations is finite, right? So if those were in some XML schema, the names could be verified at least (not meaning that the operation is actually supported).
> BTW: Would a "crm configure verify" detect this kijnd of problem?
> [...]
> Ulrich

Yes, it's in the resource agent meta-data. While pacemaker itself uses a
small set of well-defined actions, the agent may define any arbitrarily
named actions it desires, and the user could configure one of these as a
recurring action in pacemaker.

Pacemaker itself has to be liberal about where its configuration comes
from -- the configuration can be edited on a separate machine, which
doesn't have resource agents, and then uploaded to the cluster. So
Pacemaker can't do that validation at configuration time. (It could
theoretically do some checking after the fact when the configuration is
loaded, but this could be a lot of overhead, and there are
implementation issues at the moment.)

Higher-level tools like crmsh and pcs, on the other hand, can make
simplifying assumptions. They can require access to the resource agents
so that they can do extra validation.

More information about the Users mailing list