Bug 2182383

Summary: Both pacemaker-controld and pacemaker-schedulerd metadata contains 'no-quorum-policy' cluster property
Product: Red Hat Enterprise Linux 9 Reporter: Miroslav Lisik <mlisik>
Component: pacemakerAssignee: Ken Gaillot <kgaillot>
Status: NEW --- QA Contact: cluster-qe <cluster-qe>
Severity: low Docs Contact:
Priority: low    
Version: 9.2CC: cluster-maint, tojeline
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Miroslav Lisik 2023-03-28 13:54:34 UTC
Description of problem:
Both pacemaker-controld and pacemaker-schedulerd metadata contains 'no-quorum-policy' cluster property.

Version-Release number of selected component (if applicable):
pacemaker-2.1.5-7.el9

How reproducible:
always



Steps to Reproduce:
/usr/libexec/pacemaker/pacemaker-controld metadata | grep no-quorum-policy
/usr/libexec/pacemaker/pacemaker-schedulerd metadata | grep no-quorum-policy


Actual results:
Cluster property metadata for 'no-quorum-policy' is defined on both places.

Expected results:
Cluster property metadata for 'no-quorum-policy' is defined only in one deamon metadata.

Additional info:

Comment 1 Ken Gaillot 2023-03-28 14:23:30 UTC
This is not a bug per the current Pacemaker design -- each daemon defines metadata for the cluster options that it uses, and certain options are used by both the controller and scheduler. Then "enable-acl" and "cluster-ipc-limit" are used by the CIB manager (which doesn't have a metadata option) but not the controller or scheduler, so they aren't documented in metadata anywhere.

Of course, that's not an ideal design, so we can use this bz as a feature request for a single comprehensive list of cluster option metadata, similar to Bug 2163699 for meta-attributes.

Comment 2 Tomas Jelinek 2023-03-28 14:51:49 UTC
(In reply to Ken Gaillot from comment #1)
> Then "enable-acl" and "cluster-ipc-limit" are used by the CIB manager (which doesn't have a metadata option) but not the controller or scheduler, so they aren't documented in metadata anywhere.

They are documented in metadata in pacemaker-based. Pcs reads and processes metadata from pacemaker-based, otherwise it wouldn't consider "enable-acl" and "cluster-ipc-limit" to be allowed cluster properties and would require --force to be specified for them to be set.

> This is not a bug per the current Pacemaker design -- each daemon defines metadata for the cluster options that it uses, and certain options are used by both the controller and scheduler.

Just to put this bz into context:
The problem is that 'pcs property describe' then prints "no-quorum-policy" twice. And when validating a value of the property, pcs chooses one of the duplicate definitions. That's not a big deal now, but if the definitions ever start to differ, it will become a problem.

Comment 3 Ken Gaillot 2023-03-28 14:58:02 UTC
(In reply to Tomas Jelinek from comment #2)
> (In reply to Ken Gaillot from comment #1)
> > Then "enable-acl" and "cluster-ipc-limit" are used by the CIB manager (which doesn't have a metadata option) but not the controller or scheduler, so they aren't documented in metadata anywhere.
> 
> They are documented in metadata in pacemaker-based. Pcs reads and processes
> metadata from pacemaker-based, otherwise it wouldn't consider "enable-acl"
> and "cluster-ipc-limit" to be allowed cluster properties and would require
> --force to be specified for them to be set.

Huh, I always thought it didn't for some reason. Well, that's good :)
 
> > This is not a bug per the current Pacemaker design -- each daemon defines metadata for the cluster options that it uses, and certain options are used by both the controller and scheduler.
> 
> Just to put this bz into context:
> The problem is that 'pcs property describe' then prints "no-quorum-policy"
> twice. And when validating a value of the property, pcs chooses one of the
> duplicate definitions. That's not a big deal now, but if the definitions
> ever start to differ, it will become a problem.

Yep, it's just a limitation of the current design. They should always be identical (it would be a bug if they weren't).