[ClusterLabs Developers] OCF actions support

Ken Gaillot kgaillot at redhat.com
Wed Feb 12 16:33:08 EST 2020


On Wed, 2020-02-12 at 16:17 +0100, Jehan-Guillaume de Rorthais wrote:
> Last mail for today :)
> 
> At least three actions exists in the OCF specs and are not fully
> supported in
> Pacemaker.
> 
> 1. recovery
> 
>   Today, Pacemaker replace this action with a stop/start or
>   demote/stop/start/promote transition. I bet some RA (at least PAF)
> would be
>   able to deal with a recovery themselves faster in one action than
> with 2 or 4
>   actions (without counting notify).

In principle it should be possible to support "recover" when the stop
and start are scheduled on the same node. It would be similar to how
pacemaker currently changes stop+start to live migration only when
certain conditions are met.

One question would be how to handle "recover" failures. My first
instinct is that if recover fails, the cluster should switch to
stop+start, similar to a failed live migration. An alternative would be
to retry the recover action up to the migration-threshold then switch
to stop+start.

> 2. migration-to and migration-from
> 
>   These two actions are only available for non-clone resource today.
> 
>   I would really appreciate having them for multi-state resources.
> Think
>   switchover roles between primary and secondaries.

I don't follow how using that to switch roles would be different from
demote/promote with notifications.

> How hard would it be to add these actions? Is it something that could

Most changes in pacemaker are big projects; these certainly would be.
Anything that touches the scheduler tends to involve a lot of work.
There are 35K lines of scheduler-related code and it's difficult to
predict how a change in one part affects another.

> be planed
> in the futur? I'm not sure how I would be able to contribute to these
> features,
> at least with tests, maybe some code, but it really depend how hard
> it would be
> and how much time I can find to work on this.
> 
> Regards,
-- 
Ken Gaillot <kgaillot at redhat.com>



More information about the Developers mailing list