The "support or drop" part -- if we had decided to support it, this would have been a subtask. But we decided to drop it.

Fixed by rP9c13ce6fe

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#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.