[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