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. _______________________________________________ Developers mailing list [email protected] http://lists.clusterlabs.org/mailman/listinfo/developers
