[ClusterLabs Developers] Validation of resource meta-attributes

[Ondrej Mular]

On Mon, 2017-09-18 at 09:43 -0500, Ken Gaillot wrote:
> 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?

For cluster properties we are using these 3 commands:
 * /usr/libexec/pacemaker/pengine metadata
 * /usr/libexec/pacemaker/crmd metadata
 * /usr/libexec/pacemaker/cib metadata

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

That's a good point. But we can validate pacemaker defined meta-
attributes against the meta-data, and user will be able to set all
other attributes using e.g. --force parameter. So pcs will stay
consistent as it is almost at all other places where we validate user
input against any definition.

I'm not sure if there are any benefits for pacemaker validating meta-
attributes (e.g. using schema). With use of meta-data, pacemaker
doesn't need to do any validations, UIs can do it all.

Another advantage of meta-data is that we can put into it a lot of
useful information regarding meta-attributes and then possibly make it
more user-friendly to manage them.

In regards with recent depracating of some old meta-attributes before
pacemaker 2.0, in the future it will be quite easy to mark these meta-
attributes in their meta-data as deprecated, so pcs can show a warning
when user will try to set them.

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

If we will go with schema approach, pcs will still have to do
validation because otherwise pacemaker will refuse to accept invalid
CIB. These validations will have to be hardcoded into pcs according to
latest schema, and later updated if there will be some changes.