OCF metadata blocks do not support such information.
They could be extended to do so, but that is a larger effort.

This is not really a pacemaker issue, since pacemaker wouldn't supply or use the new metadata in any way. To implement this, you'd have to coordinate with the OCF folks to update the standard, and then with the various resource agent and fence agent maintainers to implement the new metadata.

Bumping this bug back to you so you can decide what to do with it next.

After discussing the idea with Andrew Beekhof, we think the best approach would be a single new metadata field (per option) for a regular expression to validate the value. Then, once the user has filled out the form, run the agent's validate action to ensure the values are all valid together.

That may not be quite as friendly as a drop-down menu, but there are too many possible variations of legal values to implement this realistically. What if option A can have different legal values based on how option B is set? What if option C is required only if options D or E are set? You would quickly get to something like an RNG schema definition, and resource agent writers can't be presumed to do that.

Forgot to add -- if you do get the OCF community to agree on something, clone this bug for pacemaker, and we'll add the new field(s) to internally generated metadata.

Re [comment 2]:

> That may not be quite as friendly as a drop-down menu, but there are
> too many possible variations of legal values to implement this
> realistically.  What if option A can have different legal values based
> on how option B is set? What if option C is required only if options
> D or E are set?  You would quickly get to something like an RNG schema
> definition,

This is what I was proposing at the HA Summit this earlier year.
You can express many complex inter-dependencies with that, and
given that native RelaxNG is also parseable XML, CLI tools could
cope with that (or a standardized subset) quite well
(enumeration of values -> drop down in webUI, etc.).

Plain regexp is a subset of what RelaxNG can handle.

> and resource agent writers can't be presumed to do that.

Provided that implicit default is "any string", using RelaxNG like
static(!) expression of valid values (overapproximation of what
the agent can evaluate OK in run-time it the specific context via
validate action) is a dramatic improvement of user experience and
as it would be optional anyway, we can contribute such enrichments
to the agents we are interested in.

FAs based on fencing.py could generate it more automatically
provided that mutual exclusion and other inter-param relationships
are encoded in a suitable way.


Btw. either regexp or RelaxNG approach could finally mark fields
that cannot contain any whitespace (in radix) to avoid triggering
bugs connected with extremely difficult proper handling in shell
based agents:
http://oss.clusterlabs.org/pipermail/users/2015-May/000403.html

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Reopening and moving to pacemaker to consider migrating pacemaker-generated metadata ('/usr/libexec/pacemaker/pacemaker-fenced metadata', '/usr/libexec/pacemaker/pacemaker-schedulerd metadata', '/usr/libexec/pacemaker/pacemaker-controld metadata', '/usr/libexec/pacemaker/pacemaker-based metadata') to OCF 1.1. The main idea is to move lists of allowed values from 'longdesc' to 'option' elements in 'content' element - see comment 0.

Thanks, I've been meaning to circle back around to this

For ease of tracking, I am moving this bz to RHEL 8.6 since the fix is expected in both 8.6 and 9.0GA. The fix will be tested for 9.0 as part of the 9.0 rebase bz.

Fixed upstream as of commit 4f9c7ef6

[root@virt-134 ~]# rpm -q pacemaker
pacemaker-2.1.2-2.el8.x86_64

[root@virt-134 ~]# /usr/libexec/pacemaker/pacemaker-schedulerd metadata | head -n 15
<?xml version="1.0"?><!DOCTYPE resource-agent SYSTEM "ra-api-1.dtd">
<resource-agent name="pacemaker-schedulerd">
  <version>1.1</version>
  <longdesc lang="en">Cluster options used by Pacemaker's scheduler (formerly called pengine)</longdesc>
  <shortdesc lang="en">Pacemaker scheduler options</shortdesc>
  <parameters>
    <parameter name="no-quorum-policy">
      <shortdesc lang="en">What to do when the cluster does not have quorum</shortdesc>
      <longdesc lang="en">What to do when the cluster does not have quorum  Allowed values: stop, freeze, ignore, demote, suicide</longdesc>
      <content type="select" default="stop">
        <option value="stop" />
        <option value="freeze" />
        <option value="ignore" />
        <option value="demote" />
        <option value="suicide" />

verified as SanityOnly in pacemaker-2.1.2-2.el8

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/RHBA-2022:1885