Fixed by rP9c13ce6fe

This gets the right result (well, with an extra newline) but I don't like it:

The problem is that pcmk__xml2fd takes an xmlNode *, not an xmlDoc *. Printing an XML_DOCUMENT_NODE is what causes the version to be printed out. So we'd either need to change that function or make a new one, and then have xml_finish pass the document pointer instead of the root node.

In T620#11130, @nrwahl2 wrote:

In T620#11098, @kgaillot wrote:

I think it would make sense if we were designing from scratch, but crm_attribute actually is the intended place for this. It has always been used to manage cluster options as well as node attributes.

Okay, that makes sense for cluster options. I'm still not sure it makes sense to put local options there, or to put meta-attributes for alerts, resources, and ops there.

I'm not at that point yet, still finishing up cluster options, but the rest should move faster with the infrastructure in place and the approach settled on.

In T620#11098, @kgaillot wrote:

I think it would make sense if we were designing from scratch, but crm_attribute actually is the intended place for this. It has always been used to manage cluster options as well as node attributes.

shrug

In T620#11067, @nrwahl2 wrote:

In T620#10980, @kgaillot wrote:

If it doesn't require anything outside libcrmcommon, I would put the bulk of it there. When we get to the UI (command-line options), the highest-level equivalents of that should be in libpacemaker.
...
The libcrmcommon functions would do all the processing, and the libpacemaker functions would focus on output

That's basically the conundrum. Output is the only thing we're dealing with (there's no meaningful processing otherwise), but the output functions need access to an array that lives in libcrmcommon. There are many ways to approach this that would work. The question is which one's the cleanest and most in line with our existing code.

It looks like doxygen implements its own C source scanner. I wonder if it has issues with variadic macros.

I assume you are building without -DPCMK__WITH_ATTRIBUTE_OUTPUT_ARGS, right? In that case, PCMK__OUTPUT_ARGS is defined to nothing. So, that's weird.

How do you feel about a new lightweight CLI tool called something like pcmk_option? I think I can get this into crm_attribute relatively easily. It's just that none of these are attributes.

In T620#10980, @kgaillot wrote:

If it doesn't require anything outside libcrmcommon, I would put the bulk of it there. When we get to the UI (command-line options), the highest-level equivalents of that should be in libpacemaker.
...
The libcrmcommon functions would do all the processing, and the libpacemaker functions would focus on output

Inform Fabio when it's fixed

In T620#10979, @nrwahl2 wrote:

Do we want the "list cluster options" command to go in libpacemaker, or libcrmcommon?