I agree this is unfortunate. The problem is, that users are allowed to set custom meta attributes for their purposes [1]. So there are no 'invalid' meta attributes, there are just meta attributes ignored by pacemaker. Implementing the requested validation would break the use case of setting custom meta attributes. Ken, what's your opinion?

[1]: https://clusterlabs.org/pacemaker/doc/2.1/Pacemaker_Explained/singlehtml/index.html#resource-meta-attributes

Maybe just a warning (without requiring --force) that the specified meta attribute doesn't match any cluster-defined ones, and the user should make sure they're intentionally setting a custom attribute? That way we don't add friction to a valid use case and possibly break scripts.

A warning makes sense. I don't see a problem with requiring --force, but you might want to save that for the next major version.

Pacemaker's behavior is less than ideal here, but changing it would be a massive compatibility break. If we did want to change it, I'd probably keep meta_attributes for user-defined attributes and move the Pacemaker-aware ones to new element(s). But that would be at least a major version away and would keep the old support deprecated for at least another major version.

Thanks for your input. We can go with printing a warning and possibly require --force in the next major version.

Ken, does pacemaker provide a definition of supported meta attributes? Something similar to '/usr/libexec/pacemaker/pacemaker-schedulerd metadata'?

(In reply to Tomas Jelinek from comment #5)
> Thanks for your input. We can go with printing a warning and possibly
> require --force in the next major version.
> 
> Ken, does pacemaker provide a definition of supported meta attributes?
> Something similar to '/usr/libexec/pacemaker/pacemaker-schedulerd metadata'?

No. That information is currently not collected or collectable anywhere. Also, meta-attributes are effective only in certain contexts (for example clone-max only matters inside a clone element). So this will not be practical from the pcs side.

I think the only way we could make this simple would be to use a new attributes block for Pacemaker-aware properties, and have the schema enumerate which are allowed where. Then we could rely on schema validation, and pcs wouldn't need any changes. Something like:

    <primitive id="rsc1" ...>
        <control id="...">  <!-- for Pacemaker-aware properties -->
            <nvpair .../>
        </control>
        <meta_attributes id="..."> <!-- for user use, and backward compatibility -->
            <nvpair .../>
        </meta_attributes>
        <instance_attributes id="..."/> <!-- for agent parameters -->
            <nvpair .../>
        </instance_attributes>
    </primitive>

pcs could add a new [control <control options> ...] syntax to commands, but that would require users to change their behavior. Alternatively, pcs could continue using meta for control options, and add a new syntax for user-defined meta_attributes, which would be safer but somewhat confusing.

Thoughts?

(In reply to Ken Gaillot from comment #6)
> (In reply to Tomas Jelinek from comment #5)
> > Thanks for your input. We can go with printing a warning and possibly
> > require --force in the next major version.
> > 
> > Ken, does pacemaker provide a definition of supported meta attributes?
> > Something similar to '/usr/libexec/pacemaker/pacemaker-schedulerd metadata'?
> 
> 
> I think the only way we could make this simple would be to use a new
> attributes block for Pacemaker-aware properties, and have the schema
> enumerate which are allowed where. Then we could rely on schema validation,
> and pcs wouldn't need any changes. Something like:
> 
>     <primitive id="rsc1" ...>
>         <control id="...">  <!-- for Pacemaker-aware properties -->
>             <nvpair .../>
>         </control>
>         <meta_attributes id="..."> <!-- for user use, and backward compatibility -->
>             <nvpair .../>
>         </meta_attributes>
>         <instance_attributes id="..."/> <!-- for agent parameters -->
>             <nvpair .../>
>         </instance_attributes>
>     </primitive>

This doesn't really help. Even if meta-attributes were validated by schema, pcs would have to do its own validation to prevent 'CIB does not conform to schema' errors. From my point of view, this solution adds complexity and backward compatibility problems, while not getting us closer to solution. In the worst case, pcs would have to keep it's own list of allowed meta-attributes' names, possibly lagging behind pacemaker.


Having a definition of meta-attributes provided by pacemaker seems like a better approach to me. If meta-attributes are context dependent, let's build that info into the definition. Either as a CLI option (e.g. pcmk-metaattrs-tool metadata --context primitive|group|bundle|clone|promotable|operation|rsc-defaults|op-defaults) or into XML output as an attribute or element. Thinking about it, a CLI option sounds better, as it would allow using existing OCF schema for the XML.

If meta-attributes were defined this way, pcs could use it to validate both their names and values as well as to print meta-attributes names and their description in a similar manner it does with instance-attributes.

Opinions?

(In reply to Tomas Jelinek from comment #7)
> Even if meta-attributes were validated by schema,
> pcs would have to do its own validation to prevent 'CIB does not conform to
> schema' errors. From my point of view, this solution adds complexity and
> backward compatibility problems, while not getting us closer to solution. In
> the worst case, pcs would have to keep it's own list of allowed
> meta-attributes' names, possibly lagging behind pacemaker.

Definitely want to avoid that

> Having a definition of meta-attributes provided by pacemaker seems like a
> better approach to me. If meta-attributes are context dependent, let's build
> that info into the definition. Either as a CLI option (e.g.
> pcmk-metaattrs-tool metadata --context
> primitive|group|bundle|clone|promotable|operation|rsc-defaults|op-defaults)
> or into XML output as an attribute or element. Thinking about it, a CLI
> option sounds better, as it would allow using existing OCF schema for the
> XML.
> 
> If meta-attributes were defined this way, pcs could use it to validate both
> their names and values as well as to print meta-attributes names and their
> description in a similar manner it does with instance-attributes.
> 
> Opinions?

That does make more sense. We can clone this bz for the Pacemaker side.

*** Bug 1415234 has been marked as a duplicate of this bug. ***

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.