1885293 – Support new role terminology in pacemaker 2.1

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1885293 - Support new role terminology in pacemaker 2.1

Summary: Support new role terminology in pacemaker 2.1

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 8
Classification:	Red Hat
Component:	pcs
Sub Component:
Version:	8.3
Hardware:	Unspecified
OS:	Unspecified
Priority:	high
Severity:	high
Target Milestone:	rc
Target Release:	8.5
Assignee:	Ondrej Mular
QA Contact:	cluster-qe@redhat.com
Docs Contact:	Steven J. Levine
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2020-10-05 14:30 UTC by Tomas Jelinek
Modified:	2022-04-01 17:44 UTC (History)
CC List:	12 users (show)
Fixed In Version:	pcs-0.10.10-1.el8
Doc Type:	Enhancement
Doc Text:	.`pcs` now accepts `Promoted` and `Unpromoted` as role names The `pcs` command-line interface now accepts `Promoted` and `Unpromoted` anywhere roles are specified in Pacemaker configuration. These role names are the functional equivalent of the `Master` and `Slave` Pacemaker roles. `Master` and `Slave` remain the names for these roles in configuration displays and help text.
Clone Of:
Environment:
Last Closed:	2021-11-09 17:33:51 UTC
Type:	Bug
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Links
System	ID	Priority	Status	Summary	Last Updated
Red Hat Issue Tracker	CLUSTERQE-4863	None	None	None	2021-08-25 14:20:10 UTC
Red Hat Knowledge Base (Solution)	3890581	None	None	None	2022-04-01 17:26:15 UTC
Red Hat Product Errata	RHSA-2021:4142	None	None	None	2021-11-09 17:34:43 UTC

Internal Links: 1936833

Description Tomas Jelinek 2020-10-05 14:30:22 UTC

In version 2.1, pacemaker is moving away from master/slave roles, the new names for those are going to be promoted/demoted. This needs to be reflected in pcs:

* New roles are going to be used in crm_mon xml output. If pcs is looking for roles in there, it must be able to work with both old and new roles.

* New roles are going to be used in CIB. Even though pacemaker will support both old and new roles, pcs should print the new ones. Pcs also needs to accept both old and new roles, and print a deprecation warning when an old role is used. This is crucial so that the old roles can be removed in next release.

Comment 1 Tomas Jelinek 2020-10-05 14:35:27 UTC

Upstream info: https://wiki.clusterlabs.org/wiki/Pacemaker_2.1_Changes

Comment 14 Ondrej Mular 2021-08-19 07:26:36 UTC

Upstream patches:
https://github.com/ClusterLabs/pcs/commit/e42260f17a7dcf93cb90d10543b4076488bc56ee
https://github.com/ClusterLabs/pcs/commit/90c09222656cd8bbf1231e923f1f4106a0ab320c

Comment 15 Ondrej Mular 2021-08-19 11:16:51 UTC

Test:
[root@rhel85-devel1 ~]# rpm -q pcs
pcs-0.10.10-1.el8.x86_64
[root@rhel85-devel1 ~]# pcs resource create stateful-rsc stateful op monitor interval=5s role=Promoted --wait
Assumed agent name 'ocf:pacemaker:Stateful' (deduced from 'stateful')
Waiting for the cluster to apply configuration changes...
resource 'stateful-rsc' is running on node 'rhel85-devel1'
[root@rhel85-devel1 ~]# pcs resource config stateful-rsc
 Resource: stateful-rsc (class=ocf provider=pacemaker type=Stateful)
  Operations: demote interval=0s timeout=10s (stateful-rsc-demote-interval-0s)
              monitor interval=5s role=Master (stateful-rsc-monitor-interval-5s)
              notify interval=0s timeout=5s (stateful-rsc-notify-interval-0s)
              promote interval=0s timeout=10s (stateful-rsc-promote-interval-0s)
              reload-agent interval=0s timeout=10s (stateful-rsc-reload-agent-interval-0s)
              start interval=0s timeout=20s (stateful-rsc-start-interval-0s)
              stop interval=0s timeout=20s (stateful-rsc-stop-interval-0s)

Comment 20 Michal Mazourek 2021-08-26 14:57:09 UTC

BEFORE:
=======

[root@virt-531 ~]# rpm -q pcs
pcs-0.10.8-1.el8.x86_64

[root@virt-531 ~]# pcs resource create stateful-rsc stateful op monitor interval=5s role=Promoted --wait
Assumed agent name 'ocf:pacemaker:Stateful' (deduced from 'stateful')
Error: 'Promoted' is not a valid role value, use 'Master', 'Slave', 'Started', 'Stopped'
Error: Errors have occurred, therefore pcs is unable to continue

> pcs is not accepting promoted/unpromoted terminology


AFTER:
======

[root@virt-131 ~]# rpm -q pcs
pcs-0.10.10-1.el8.x86_64


## Creating resources with Promoted/Unpromoted roles

[root@virt-131 ~]# pcs resource create stateful-rsc stateful op monitor interval=5s role=Promoted --wait
Assumed agent name 'ocf:pacemaker:Stateful' (deduced from 'stateful')
Waiting for the cluster to apply configuration changes...
resource 'stateful-rsc' is running on node 'virt-131'
[root@virt-131 ~]# echo $?
0

[root@virt-131 ~]# pcs resource create stateful-rsc-2 stateful op monitor interval=5s role=Unpromoted --wait
Assumed agent name 'ocf:pacemaker:Stateful' (deduced from 'stateful')
Waiting for the cluster to apply configuration changes...
resource 'stateful-rsc-2' is running on node 'virt-132'
[root@virt-131 ~]# echo $?
0

> OK: A new terminology can be used in role


[root@virt-131 ~]# pcs resource config 
 Resource: stateful-rsc (class=ocf provider=pacemaker type=Stateful)
  Operations: demote interval=0s timeout=10s (stateful-rsc-demote-interval-0s)
              monitor interval=5s role=Master (stateful-rsc-monitor-interval-5s)
              notify interval=0s timeout=5s (stateful-rsc-notify-interval-0s)
              promote interval=0s timeout=10s (stateful-rsc-promote-interval-0s)
              reload-agent interval=0s timeout=10s (stateful-rsc-reload-agent-interval-0s)
              start interval=0s timeout=20s (stateful-rsc-start-interval-0s)
              stop interval=0s timeout=20s (stateful-rsc-stop-interval-0s)
 Resource: stateful-rsc-2 (class=ocf provider=pacemaker type=Stateful)
  Operations: demote interval=0s timeout=10s (stateful-rsc-2-demote-interval-0s)
              monitor interval=5s role=Slave (stateful-rsc-2-monitor-interval-5s)
              notify interval=0s timeout=5s (stateful-rsc-2-notify-interval-0s)
              promote interval=0s timeout=10s (stateful-rsc-2-promote-interval-0s)
              reload-agent interval=0s timeout=10s (stateful-rsc-2-reload-agent-interval-0s)
              start interval=0s timeout=20s (stateful-rsc-2-start-interval-0s)
              stop interval=0s timeout=20s (stateful-rsc-2-stop-interval-0s)

> A role are still shown as Master/Slave in config. After discussion with developers, this is expected for RHEL8 - Master/Slave roles are still primary and will be shown everywhere, but Promoted/Unpromoted can be parsed too. This will be the other way round in RHEL9 (primary will be Promoted/Unpromoted).


[root@virt-131 ~]# pcs resource create stateful-rsc-3 stateful op monitor interval=5s role=test --wait
Assumed agent name 'ocf:pacemaker:Stateful' (deduced from 'stateful')
Error: 'test' is not a valid role value, use 'Master', 'Promoted', 'Slave', 'Started', 'Stopped', 'Unpromoted'
Error: Errors have occurred, therefore pcs is unable to continue

> OK


[root@virt-131 ~]# pcs resource create stateful-rsc-3 stateful op monitor interval=5s role=promoted --wait
Assumed agent name 'ocf:pacemaker:Stateful' (deduced from 'stateful')
Waiting for the cluster to apply configuration changes...
resource 'stateful-rsc-3' is running on node 'virt-131'
[root@virt-131 ~]# echo $?
0

[root@virt-131 ~]# pcs resource create stateful-rsc-4 stateful op monitor interval=5s role=UNPROMOTED --wait
Assumed agent name 'ocf:pacemaker:Stateful' (deduced from 'stateful')
Waiting for the cluster to apply configuration changes...
resource 'stateful-rsc-4' is running on node 'virt-132'
[root@virt-131 ~]# echo $?
0

> OK: The roles are not case sensitive


[root@virt-131 ~]# pcs resource create stateful-rsc-5 stateful op monitor interval=5s role=master --wait
Assumed agent name 'ocf:pacemaker:Stateful' (deduced from 'stateful')
Waiting for the cluster to apply configuration changes...
resource 'stateful-rsc-5' is running on node 'virt-131'
[root@virt-131 ~]# echo $?
0

[root@virt-131 ~]# pcs resource create stateful-rsc-6 stateful op monitor interval=5s role=slave --wait
Assumed agent name 'ocf:pacemaker:Stateful' (deduced from 'stateful')
Waiting for the cluster to apply configuration changes...
resource 'stateful-rsc-6' is running on node 'virt-132'
[root@virt-131 ~]# echo $?
0

> OK: Master/Slave still can be used

[root@virt-131 ~]# pcs resource config | grep role -B 2
 Resource: stateful-rsc (class=ocf provider=pacemaker type=Stateful)
  Operations: demote interval=0s timeout=10s (stateful-rsc-demote-interval-0s)
              monitor interval=5s role=Master (stateful-rsc-monitor-interval-5s)
--
 Resource: stateful-rsc-2 (class=ocf provider=pacemaker type=Stateful)
  Operations: demote interval=0s timeout=10s (stateful-rsc-2-demote-interval-0s)
              monitor interval=5s role=Slave (stateful-rsc-2-monitor-interval-5s)
--
 Resource: stateful-rsc-3 (class=ocf provider=pacemaker type=Stateful)
  Operations: demote interval=0s timeout=10s (stateful-rsc-3-demote-interval-0s)
              monitor interval=5s role=Master (stateful-rsc-3-monitor-interval-5s)
--
 Resource: stateful-rsc-4 (class=ocf provider=pacemaker type=Stateful)
  Operations: demote interval=0s timeout=10s (stateful-rsc-4-demote-interval-0s)
              monitor interval=5s role=Slave (stateful-rsc-4-monitor-interval-5s)
--
 Resource: stateful-rsc-5 (class=ocf provider=pacemaker type=Stateful)
  Operations: demote interval=0s timeout=10s (stateful-rsc-5-demote-interval-0s)
              monitor interval=5s role=Master (stateful-rsc-5-monitor-interval-5s)
--
 Resource: stateful-rsc-6 (class=ocf provider=pacemaker type=Stateful)
  Operations: demote interval=0s timeout=10s (stateful-rsc-6-demote-interval-0s)
              monitor interval=5s role=Slave (stateful-rsc-6-monitor-interval-5s)

> OK


## Testing other commands with a role

[root@virt-131 ~]# pcs constraint colocation add --help

Usage: pcs constraint [constraints]...
    colocation add [<role>] <source resource id> with [<role>]
                   <target resource id> [score] [options] [id=constraint-id]
        Request <source resource> to run on the same node where pacemaker has
        determined <target resource> should run.  Positive values of score
        mean the resources should be run on the same node, negative values
        mean the resources should not be run on the same node.  Specifying
        'INFINITY' (or '-INFINITY') for the score forces <source resource> to
        run (or not run) with <target resource> (score defaults to "INFINITY").
        A role can be: 'Master', 'Slave', 'Started', 'Stopped' (if no role is
        specified, it defaults to 'Started').

> Master/Slave roles are still primary, as mentioned above, so documentation doesn't mention Promoted/Unpromoted yet. It will be other way around in RHEL9.


# colocation

[root@virt-131 ~]# pcs constraint colocation add Promoted stateful-rsc with Unpromoted stateful-rsc-2
[root@virt-131 ~]# echo $?
0
[root@virt-131 ~]# pcs constraint
Location Constraints:
Ordering Constraints:
Colocation Constraints:
  stateful-rsc with stateful-rsc-2 (score:INFINITY) (rsc-role:Master) (with-rsc-role:Slave)
Ticket Constraints:

> OK


# colocation set

[root@virt-131 ~]# pcs constraint colocation set stateful-rsc-3 stateful-rsc-4 role=Promoted
[root@virt-131 ~]# echo $?
0
[root@virt-131 ~]# pcs constraint
Location Constraints:
Ordering Constraints:
Colocation Constraints:
  stateful-rsc with stateful-rsc-2 (score:INFINITY) (rsc-role:Master) (with-rsc-role:Slave)
  Resource Sets:
    set stateful-rsc-3 stateful-rsc-4 role=Master setoptions score=INFINITY
Ticket Constraints:

> OK


# ticket

[root@virt-131 ~]# pcs constraint ticket add test Promoted stateful-rsc-6
[root@virt-131 ~]# echo $?
0
[root@virt-131 ~]# pcs constraint 
Location Constraints:
Ordering Constraints:
Colocation Constraints:
  stateful-rsc with stateful-rsc-2 (score:INFINITY) (rsc-role:Master) (with-rsc-role:Slave)
  Resource Sets:
    set stateful-rsc-3 stateful-rsc-4 role=Master setoptions score=INFINITY
Ticket Constraints:
  Master stateful-rsc-6 ticket=test

> OK


# ticket set

[root@virt-131 ~]# pcs constraint ticket set stateful-rsc-4 stateful-rsc-5 role=Promoted setoptions ticket=test
[root@virt-131 ~]# echo $?
0
[root@virt-131 ~]# pcs constraint
Location Constraints:
Ordering Constraints:
Colocation Constraints:
  stateful-rsc with stateful-rsc-2 (score:INFINITY) (rsc-role:Master) (with-rsc-role:Slave)
  Resource Sets:
    set stateful-rsc-3 stateful-rsc-4 role=Master setoptions score=INFINITY
Ticket Constraints:
  Master stateful-rsc-6 ticket=test
  Resource Sets:
    set stateful-rsc-4 stateful-rsc-5 role=Master setoptions ticket=test

> OK


# rule

[root@virt-131 ~]# pcs constraint location add loc1 stateful-rsc virt-131 10
[root@virt-131 ~]# pcs constraint rule add loc1 role=Unpromoted date gt 01-01-2021
[root@virt-131 ~]# echo $?
0
[root@virt-131 ~]# pcs constraint
Location Constraints:
  Resource: stateful-rsc
    Constraint: loc1
      Rule: role=Slave score=INFINITY
        Expression: date gt 01-01-2021
Ordering Constraints:
Colocation Constraints:
  stateful-rsc with stateful-rsc-2 (score:INFINITY) (rsc-role:Master) (with-rsc-role:Slave)
  Resource Sets:
    set stateful-rsc-3 stateful-rsc-4 role=Master setoptions score=INFINITY
Ticket Constraints:
  Master stateful-rsc-6 ticket=test
  Resource Sets:
    set stateful-rsc-4 stateful-rsc-5 role=Master setoptions ticket=test

> OK


## commands, that are using master as an option

[root@virt-131 ~]# man pcs | grep "\-\-master"
       move <resource id> [destination node] [--master] [[lifetime=<lifetime>] | [--autodelete [--strict]]] [--wait[=n]]
              fer  the destination node. If --master is used the scope of the command is limited to the master role and you must use the
       ban <resource id> [node] [--master] [lifetime=<lifetime>] [--wait[=n]]
              fied) by creating a -INFINITY location constraint. If --master is used the scope of the command is limited to  the  master
       clear <resource id> [node] [--master] [--expired] [--wait[=n]]
              Remove  constraints  created by move and/or ban on the specified resource (and node if specified). If --master is used the

[root@virt-131 ~]# pcs resource create promotable1 stateful promotable
[root@virt-131 ~]# pcs resource move promotable1-clone virt-131 --promoted
{...}
option --promoted not recognized

> option --master doesn't have its promoted variant yet, but will have in RHEL9


CONCLUSION:
===========
A new terminology Promoted/Unpromoted is now supported in roles.  
Based on a discussion with developers, Master/Slave terminology is still primary in this release. Because of that, master/slave terminology is visible in configurations and help pages, but pcs is newly accepting promoted/unpromoted as well. In RHEL9, it will be the other way round, pcs will still accept master/slave terminology, but promoted/unpromoted will be the primary one. This goes for the --master option as well.
Marking as VERIFIED for pcs-0.10.10-1.el8

Comment 33 errata-xmlrpc 2021-11-09 17:33:51 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Low: pcs security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:4142

Note You need to log in before you can comment on or make changes to this bug.