Meta-attribute inheritance is weird. I've just started looking at groups. Very much non-exhaustive:

• is-managed: Any false wins. If is-managed=false for the group and is-managed=true for a primitive, the primitive is unmanaged.
• maintenance: Any true wins. Similar to is-managed but reversed.
• resource-stickiness: Group's stickiness is used as the default for a primitive's stickiness. Primitive's stickiness overrides (does not add to) group's stickiness.
• target-role: Same as resource-stickiness. The group's value is only a default. In particular, if the group has target-role=Stopped and the first member has target-role=Started, the first member is allowed to run.

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

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.

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

In T620#10979, @nrwahl2 wrote:

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

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

In T620#10902, @nrwahl2 wrote:

However, I'm not sure whether you wanted to include meta-attributes that can be set on a collective for the sole purpose of being inherited by a primitive (sort of the opposite scenario compared to the one above).

• On the one hand: it's cleaner and clearer not to include them, and to include only those meta-attributes that have a direct effect on the collective. We can simply ensure it's documented (maybe it already is) that primitives inherit all of their parents' meta-attributes. That implies that any primitive meta-attribute can be set on a collective for the purpose of inheritance.
• On the other hand: excluding them offloads more work to external tools. For example, if pcs is validating meta-attributes for a bundle, then it needs to check the list of bundle meta-attributes, the list of primitive meta-attributes, and maybe the list of clone meta-attributes. That's not a deal-breaker, but it requires that extra knowledge of Pacemaker behavior be built into external tools.

For the purposes of showing lists, I would think we want to show the meta-attributes that can apply directly to the thing being requested (not just inherited).

In T620#10892, @nrwahl2 wrote:

If we're using C as the starting point, we don't need XML, we just need tools that can parse the C code (we can require a particular style to make that easier) and generate sysconfig, ReST, and Python.

Running a command that generates XML on demand (which is our main goal anyway), and then parsing that, is probably easier than parsing the C code.

If we're using C as the starting point, we don't need XML, we just need tools that can parse the C code (we can require a particular style to make that easier) and generate sysconfig, ReST, and Python.