[ClusterLabs Developers] Validation of resource meta-attributes

[Ken Gaillot]

On Mon, 2017-09-18 at 13:09 +0200, Ondrej Mular wrote:
> Hi all,
> 
> during summit in Nuremberg, there was a discussion about improving
> usability. One of mentioned areas was validation of resource meta-
> attributes.
> 
> There was an idea to have meta-attributes as element attributes of
> resource elements (primitive/group/clone/master/bundle) in CIB. With
> this approach meta-attributes will be validated directly against CIB
> scheme. But this idea was rejected right away because it doesn't work
> with meta-attributes used with rules.
> 
> Maybe better way to solve this would be to do it in similar fashion
> as
> cluster properties. Pacemaker provides definition of cluster
> properties
> in same XML metadata format as resource-agents have.

What command does pcs use to get this meta-data?

> If we can obtain definition of meta-attributes metadata from
> pacemaker
> in similar format, then each CLI can validate meta-attributes against
> this definition and in GUI setting of them can be more user friendly.
> Also, we can take advantage of this format and put there some
> understandable description (maybe also name/label of meta-attribute)
> and much more. Actually, marx is working on some improvements of ocf
> XML metadata format so we can have more useful information for UIs.
> 
> Currently, pcs doesn't do any validation of resource meta-attributes.
> We were thinking about some validation, but we will have to hardcode
> it
> into pcs and update it every time some changes happen in pacemaker.
> With metadata approach, change in definition would be sufficient.
> 
> What is your opinion on this?
> 
> Ondrej
> 

It sounds like a clean solution. I like that it would be equivalent to
how instance attributes are validated. We'd need separate meta-data for
resource, operation, clone, master/slave, and alert meta-attributes.

Users are allowed to define arbitrary meta-attributes for their own
use, so we'd need something like validate="false" to continue to allow
that.

I think the schema approach is still an option. We could do something
like:

  <primitive ...>
    <options>
      <rule ... >
       <expression ... />
      </rule>
      <managed value="false" />
      <stickiness value="100" />
    </options>
  </primitive>

-- 
Ken Gaillot <kgaillot at redhat.com>