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.

Definitely, we can do a better job in determining correctness of the given
cluster stack configuration (in the form of cluster.conf).  What currently
validates successfully is a very rough overapproximation of actually
correct and sound configuration.  Granted, the ideas behind original
Relax NG schema modularization ([bug 680930], virtually first milestone
on this road) are to preserved.

This bug is to both (1) track the work in this direction in the cman's
package scope and (2) to be blocked by subordinate bugs for other packages
involved (fence-agents, resource-agents, etc.).  This bug should serve as
a central point for any discussion on the (generalized) topic.

For (1), current progress is captured in the cluster-devel ML [1] (with
many back-and-forth iterations due to the complex nature of the changes)
and in branches following STABLE32 [2] and (dependent) RHEL65 [3] ones.

[1] http://www.redhat.com/archives/cluster-devel/2013-December/msg00037.html
    http://www.redhat.com/archives/cluster-devel/2013-December/msg00052.html
    http://www.redhat.com/archives/cluster-devel/2013-December/msg00084.html
    http://www.redhat.com/archives/cluster-devel/2013-December/msg00088.html
    http://www.redhat.com/archives/cluster-devel/2013-December/msg00125.html
    http://www.redhat.com/archives/cluster-devel/2013-December/msg00134.html

[2] https://git.fedorahosted.org/cgit/cluster.git/log/?h=STABLE32-feature-schema-hardening
[3] https://git.fedorahosted.org/cgit/cluster.git/log/?h=RHEL6x-feature-schema-hardening

> ([bug 680930], virtually first milestone on this road)

because of the vital decentralization of the "correctness" knowledge,
shifting it towards particular components

Another thing that should have been captured in the schema:
https://git.fedorahosted.org/cgit/cluster.git/commit/?h=STABLE32-feature-schema-hardening&id=a6bdeb5bb4d6137e315a6c19a8d72f1ecb2cec0a

Another discovery (thanks to Piyush Sharma):

/cluster/rm/resources/action -> wrong
/cluster/rm/resources/SOMETHING/action -> ok (for SOMETHING in clusterfs, ip, ...)

As a side effect, wrongly-alleged-valid first case is what makes luci
choke: [bug 1173942].

re [comment 7]:
...as per rgmanager's code examination

Definitely 6.8 material.

[comment 10] applies just to [comment 7] that should rather be tracked
separately: [bug 1272587].

Not worth to pursuit at this point in the release cycle.
Unlike related [bug 1173942] that I am going to reopen.