[Pacemaker] crmsh: New syntax for location constraints, suggestions / comments

[Kristoffer Grönlund]

Hi everyone,

As some of you may know, I have started developing crmsh together with
Dejan, and have been working on new features for an eventual
2.0-release some time next year.

Location constraints have gotten some new capabilities in recent
versions of Pacemaker, and I have some suggested syntax for support in
crmsh. I'd love to get your comments and feedback on these suggestions,
please let me know what you think!

Location constraints are now applicable to resource sets, and the
proposed syntax for this is as follows, using pseudo-syntax:

    location <id> { <resource-set> } [<score>:] <node> / rules...

So, an example would be:

    location foo { A B ( C D ) } inf: node-1

The reason I added the { and } around the resource set is to make the
parser at least somewhat unambiguous in this case, otherwise there is no
good way of telling when the resource definitions end and the rest of
the location constraint definition continues. I know there is syntax in
crmsh that already violates this, but my preference is to keep things
unambiguous if possible.

Lars (lmb) suggested that we might switch to using the { } - brackets
around resource sets everywhere for consistency. My only concern with
that would be that it would be a breaking change to the previous crmsh
syntax. Maybe that is okay when going from 1.x to 2.0, but it also
makes me a bit nervous. :)

The second new syntax is for resource patterns / regexes. Here my
suggested syntax is as follows:

location <id> /<pattern>/ [<score>:] <node> / rules...

Example:

location prefer-node-1 /*/ 100: node-1

The // is a kind of vim-style / perl-style inspired syntax, which at
least to me seems pretty intuitive. Another option would be to try to
automatically detect patterns and generate rsc= or rsc-pattern= in the
XML appropriately, like so:

location prefer-node-1 * 100: node-1

...but I think I prefer a more explicit syntax.

I'd especially be curious to know what Chris thinks about this, if
there is already support for these types of constraints in pcs or if
there is some other syntax that might make more sense. Consistency is
always good. :)

-- 
// Kristoffer Grönlund
// kgronlund at suse.com