Open jnpkrn opened 4 years ago
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).
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.
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:
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 resourceid
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 withcrm_ticket -c
that is yet to receive an entrypoint in pcs, anyway%ticket:TICKET
, ditto withcrm_ticket -c -t TICKET
for a single, named, glob-free ticketwhen
TICKET
contains a glob, result would be a sum of runningcrm_ticket -c -t T
over allT
that match the globTICKET can possibly also be specified as
(special or ordinary*)
that would respectively concerned a ticket namedspecial
and tickets matching globordinary*
level 100:
%ticket:[TICKET]@CLUSTER-SLASH-SITE-IDENTIFIER
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:
is a verbose way of querying this:
and it asks to list all local-cluster resources matching a glob
ms-ip-*
inid
that are instances of ocf::IPaddr2 resource agent(s), directly connected tot-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.