scheduler: support/backport on-fail="demote" recovery policy for promoted resources

[Rafael David Tinoco]

There is a request for the feature:

Feature: scheduler: new on-fail="demote" recovery policy for promoted…

to be backported to Ubuntu LTS versions.

[Rafael David Tinoco (rafaeldtinoco)]

This feature is in 2.0.x releases, so SRU for bionic would be out of question:

 pacemaker | 1.1.18-0ubuntu1 | bionic | source
 pacemaker | 1.1.18-0ubuntu1.1 | bionic-security | source
 pacemaker | 1.1.18-0ubuntu1.2 | bionic-updates | source
 pacemaker | 2.0.1-4ubuntu2 | eoan | source
 pacemaker | 2.0.3-3ubuntu3 | focal | source
 pacemaker | 2.0.4-2ubuntu1 | groovy | source

and Eoan is not LTS so the effort is not worth.

That would make the need for:

To backport

(1)

874f75e0f - Feature: scheduler: new on-fail="demote" recovery policy for promoted resources
2f1e2df1f - Feature: xml: add on-fail="demote" option to resources schema

and all related patches to Focal.

(2)

To make sure Groovy catches up with the feature or to backport similar patches to Groovy.

[Rafael David Tinoco (rafaeldtinoco)]

-------- Forwarded Message --------
Subject: [ClusterLabs] Coming in Pacemaker 2.0.5: on-fail=demote / no-quorum-policy=demote
Date: Mon, 10 Aug 2020 11:47:24 -0500
From: Ken Gaillot <email address hidden>
Reply-To: Cluster Labs - All topics related to open-source clustering welcomed <email address hidden>
Organization: Red Hat
To: Cluster Labs - All topics related to open-source clustering welcomed <email address hidden>

Hi all,

Looking ahead to the Pacemaker 2.0.5 release expected at the end of
this year, here is a new feature already in the master branch.

When configuring resource operations, Pacemaker lets you set an "on-
fail" policy to specify whether to restart the resource, fence the
node, etc., if the operation fails. With 2.0.5, a new possible value
will be "demote", which will mean "demote this resource but do not
fully restart it".

"Demote" will be a valid value only for promote actions, and for
recurring monitors with "role" set to "Master".

Once the resource is demoted, it will be eligible for promotion again,
so if the promotion scores have not changed, a promote on the same node
may be attempted. If this is not desired, the agent can change the
promotion scores either in the failed monitor or the demote.

The intended use case is an application where a successful demote assures a well-functioning service, and a full restart would be
unnecessarily heavyweight. A large database might be an example.

Similarly, Pacemaker offers the cluster-wide "no-quorum-policy" option
to specify what happens to resources when quorum is lost (the default
being to stop them). With 2.0.5, "demote" will be a possible value here
as well, and will mean "demote all promotable resources and stop all
other resources".

The intended use case is an application that cannot cause any harm
after being demoted, and may be useful in a demoted role even if there
is no quorum. A database that operates read-only when demoted and
doesn't depend on any non-promotable resources might be an example.

Happy clustering :)
--
Ken Gaillot <email address hidden>