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 1796824 - crm_node -l does not work inside a bundle that has pcmk_remote inside
Summary: crm_node -l does not work inside a bundle that has pcmk_remote inside
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: pacemaker
Version: 8.2
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 8.3
Assignee: Ken Gaillot
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-31 10:46 UTC by Michele Baldessari
Modified: 2020-11-04 04:01 UTC (History)
5 users (show)

Fixed In Version: pacemaker-2.0.4-4.el8
Doc Type: Bug Fix
Doc Text:
Cause: Pacemaker Remote does not proxy local client connections to pacemakerd on the connection host. Consequence: crm_node's -l and -p options do not work on a Pacemaker Remote node. Fix: crm_node -l and -p now ask the controller (which is proxied) for information rather than pacemakerd. Result: crm_node -l and -p work on a connected Pacemaker Remote node.
Clone Of:
Environment:
Last Closed: 2020-11-04 04:00:53 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 5426311 0 None None None 2020-09-23 05:08:46 UTC

Description Michele Baldessari 2020-01-31 10:46:43 UTC 
Description of problem:

So I am trying to port openstack to use a new rabbitmq resource agent [1] which is implemented as a master/slave resource. Everything works fine up to the point where the resource agent calls the following function [2]. The reason this fails is that crm_node -p errors out with:
()[root@controller-0 /etc/libqb]$ crm_node -p
error: Could not connect to cluster (is it running?)

The reason for the above is that in these containers we have the /etc/libqb/force-filesystem-sockets file present [3]. In fact if I remove it:
()[root@controller-0 /etc/libqb]$ mv force-filesystem-sockets force-filesystem-sockets.meh
()[root@controller-0 /etc/libqb]$ crm_node -p
controller-0 controller-1 controller-2 

Now I don't think I can remove force-filesystem-sockets since that would break pacemaker remote's lrmd inside the bundle. Since this RA fundamentally needs "the list of nodes belonging to the partition where the RA is running", I wonder:
A) Can we think of other means to get to crm_node -p from inside a bundle that has pcmk-remote inside of it?
B) If A) is a no-go, can we either expose this info for an RA via some OCF_KEY env variable or tweak crm_node -l/-p to work inside a bundle?

pacemaker-2.0.2-3.el8_1.2.x86_64

Thanks,
Michele

[1] https://github.com/rabbitmq/rabbitmq-server-release/blob/master/scripts/rabbitmq-server-ha.ocf
[2] https://github.com/rabbitmq/rabbitmq-server-release/blob/master/scripts/rabbitmq-server-ha.ocf#L826-L831
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1446254
Comment 1 Ken Gaillot 2020-02-14 22:10:50 UTC 
crm_node's -l and -p options contact the pacemakerd daemon to get the node list. Pacemaker Remote currently proxies connections to the controller, attribute manager, fencer, and CIB manager ... but not pacemakerd. I don't see any reason it shouldn't, so we should add that. Alternatively, we could make the controller handle those queries.
Comment 6 Ken Gaillot 2020-07-20 14:52:24 UTC 
Fixed upstream as of commit 8461509
Comment 10 Patrik Hagara 2020-09-23 10:42:58 UTC 
before (2.0.3-5.el8_2.1)
========================

> [root@virt-078 ~]# pcs status
> Cluster name: STSRHTS12473
> Cluster Summary:
>   * Stack: corosync
>   * Current DC: virt-079 (version 2.0.3-5.el8_2.1-4b1f869f0f) - partition with quorum
>   * Last updated: Wed Sep 23 12:34:42 2020
>   * Last change:  Wed Sep 23 12:34:38 2020 by root via cibadmin on virt-078
>   * 4 nodes configured
>   * 5 resource instances configured
> 
> Node List:
>   * Online: [ virt-078 virt-079 virt-080 ]
>   * RemoteOnline: [ virt-081 ]
> 
> Full List of Resources:
>   * fence-virt-078	(stonith:fence_xvm):	Started virt-079
>   * fence-virt-079	(stonith:fence_xvm):	Started virt-080
>   * fence-virt-080	(stonith:fence_xvm):	Started virt-080
>   * fence-virt-081	(stonith:fence_xvm):	Started virt-078
>   * virt-081	(ocf::pacemaker:remote):	Started virt-078
> 
> Daemon Status:
>   corosync: active/enabled
>   pacemaker: active/enabled
>   pcsd: active/enabled
> [root@virt-078 ~]# ssh virt-081 crm_node -l
> error: Could not connect to cluster (is it running?)
> [root@virt-078 ~]# ssh virt-081 crm_node -p
> error: Could not connect to cluster (is it running?)

result: `crm_node -l` and `crm_node -p` commands can not be used from pacemaker remote nodes


after (2.0.4-6.el8)
===================

> [root@virt-187 ~]# pcs status
> Cluster name: STSRHTS6022
> Cluster Summary:
>   * Stack: corosync
>   * Current DC: virt-189 (version 2.0.4-6.el8-2deceaa3ae) - partition with quorum
>   * Last updated: Wed Sep 23 12:34:47 2020
>   * Last change:  Wed Sep 23 12:32:15 2020 by root via cibadmin on virt-187
>   * 4 nodes configured
>   * 5 resource instances configured
> 
> Node List:
>   * Online: [ virt-187 virt-188 virt-189 ]
>   * RemoteOnline: [ virt-190 ]
> 
> Full List of Resources:
>   * fence-virt-187	(stonith:fence_xvm):	 Started virt-188
>   * fence-virt-188	(stonith:fence_xvm):	 Started virt-189
>   * fence-virt-189	(stonith:fence_xvm):	 Started virt-189
>   * fence-virt-190	(stonith:fence_xvm):	 Started virt-187
>   * virt-190	(ocf::pacemaker:remote):	 Started virt-187
> 
> Daemon Status:
>   corosync: active/enabled
>   pacemaker: active/enabled
>   pcsd: active/enabled
> [root@virt-187 ~]# ssh virt-190 crm_node -l
> 1 virt-187 member
> 2 virt-188 member
> 3 virt-189 member
> [root@virt-187 ~]# ssh virt-190 crm_node -p
> virt-187 virt-188 virt-189 

result: `crm_node -l` and `crm_node -p` commands can now be successfully used from pacemaker remote nodes
Comment 13 errata-xmlrpc 2020-11-04 04:00:53 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 (pacemaker 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/RHEA-2020:4804
Note You need to log in before you can comment on or make changes to this bug.