[convenience] generalization of "pcs resource status" from ID-MATCH to PATTERN

[jnpkrn]

Considering the inner (how much entities and relationships amongst them happen to be configured) complexity of clusters tend to grow, there must be a good query mechanism deisgned and implemented to filter only what's indeed desired.

To retain full compatibility, what lexically conforms to NCName specification of XML would be understood as full resource id specification as used to be.

Easy and natural extension: globs (would consider self-understood, but can explain on demand).

Then, we can consider another natural extension: whenever semicolons are spotted in the pattern provided, they are understood as a filter nn agent type, e.g. ocf:heartbeat:Dummy, :Dummy, ::Dummy, possibly combined with globs: systemd:*.

Then, it becomes really interesting, since we have still some initial easy to type characters that cannot occur with either of the above pattern decompositions.

---

I won['t restrict the fantasy here, I'll just pick what I'd like to see personally. Let's say the escape-access character is % (can be any other, though, apparently, shell-sensitives characters like a bang ! would rather be avoided).

• %ticket would select any resource immediately affected with ticket constraints, as with crm_ticket -c that is yet to receive an entrypoint in pcs, anyway

• %ticket:TICKET, ditto with crm_ticket -c -t TICKET for a single, named, glob-free ticket

  • when TICKET contains a glob, result would be a sum of running crm_ticket -c -t T over all T that match the glob

  • TICKET can possibly also be specified as (special or ordinary*) that would respectively concerned a ticket named special and tickets matching glob ordinary*

• level 100: %ticket:[TICKET]@CLUSTER-SLASH-SITE-IDENTIFIER

  • filter resources to show just those that are constrained with all (given per spec) tickets whose counterparts are enabled (respective tickets granted there) at given site -- this may sound overcomplicated, but it will be blissful for typical mutually-excluded-mirrors use cases (you will immediately get to see which resources are expected to be covered by a primary site if there's such a distinction and you are currently running this command from any "secondary" one, for instance, hence you can check whether you see "stopped" or "slave" status with these in the context of a local cluster)

Apparently, these predicates themselves shall be eligible for logical combinations as well. It would then be natural to retain the current logic of implicit OR (show FULLID1 FULLID2).

Complicated example:

pcs resource status 'ocf::IPaddr2 and ms-ip-* and %ticket:t-ip-** and %ticket:@10.2.3.4'

is a verbose way of querying this:

pcs resource status 'ocf::IPaddr2::ms-ip-*%ticket:(t-ip-*@10.2.3.4')`

and it asks to list all local-cluster resources matching a glob ms-ip-* in id that are instances of ocf::IPaddr2 resource agent(s), directly connected to t-ip-* glob-matched tickets that are currently known to be active site specified with 10.2.3.4 address.

It's all just a trivial applied set theory, moreover supported nicely in Python :-)

---

As mentioned, there would be a lot more predicates to come up with here.

[jnpkrn]

Indeed, resource status would be just for a start, it could stand practically anywhere true resource id is requested.

Another idea for the pattern: %tag:TAG (TAG is, again, further derivable per the decompositions already presented, like globbing).

[jnpkrn]

Also, + is excluded in NCName so it could be used instead of % in the above examples. I'd avoid making it to stand for and, since it rather algebraically matches meaning of or amongst the sets :-) If there was a pressing need to express and in a terse way, I'd use &, at the cost of always having to eclose the whole term in quotes for the purpose of entering the argument with a typical shell, but you will likely do that anyway, for having added some spaces around this connector for legibility, anyway.

[tomjelinek]

This is an interesting idea. However, pcs currently use crm_mon directly for displaying cluster status. That means we cannot implement this feature unless one of the following happens:

• the feature is implemented in pacemaker first
• pcs renders cluster status on its own based on xml status provided by pacemaker