This is a request to backport crm_rule to RHEL 7.

+++ This bug was initially created as a clone of Bug #1572116 +++

--- Additional comment from Chris Lumens on 2019-03-12 14:02:24 UTC ---

This is fixed by upstream commit fd91fd8e33b575810b03d2890de3ee23cb3b5e0e.

--- Additional comment from Patrik Hagara on 2019-09-04 11:16:30 UTC ---

The new "crm_rule" tool interface:

> [root@virt-141 ~]# crm_rule --help
> crm_rule - Tool for querying the state of rules
> Usage: crm_rule [options]
> Options:
>  -?, --help		This text
>  -$, --version		Version information
>  -V, --verbose		Increase debug output
> 
> Modes (mutually exclusive):
>  -c, --check		Check whether a rule is in effect
> 
> Additional options:
>  -d, --date=value	Whether the rule is in effect on a given date
>  -r, --rule=value	The ID of the rule to check
> 
> Data:
>  -X, --xml-text=value	Use argument for XML (or stdin if '-')
> 
> 
> This tool is currently experimental.
> 
> The interface, behavior, and output may change with any version of pacemaker.
> 
> 
> Report bugs to users

--- Additional comment from Patrik Hagara on 2019-09-04 13:02:36 UTC ---

> [root@virt-141 ~]# rpm -q pacemaker
> pacemaker-2.0.2-3.el8.x86_64
> [root@virt-141 ~]# pcs constraint show --full
> Location Constraints:
>   Resource: dummy
>    Constraint: ban-dummy-on-virt-142-cron
>      Rule: boolean-op=and score=-INFINITY  (id:ban-dummy-on-virt-142-cron-rule)
>        Expression: #uname eq string virt-142  (id:ban-dummy-on-virt-142-cron-expr)
>        Expression:  (id:ban-dummy-on-virt-142-cron-spec)
>          Date Spec: years=2019  (id:ban-dummy-on-virt-142-cron-spec-year)
>     Constraint: ban-dummy-on-virt-142-forever
>       Rule: boolean-op=and score=-INFINITY  (id:ban-dummy-on-virt-142-forever-rule)
>         Expression: #uname eq string virt-142  (id:ban-dummy-on-virt-142-forever-expr)
>     Constraint: cli-ban-dummy-on-virt-141
>       Rule: boolean-op=and score=-INFINITY  (id:cli-ban-dummy-on-virt-141-rule)
>         Expression: #uname eq string virt-141  (id:cli-ban-dummy-on-virt-141-expr)
>         Expression: date gt 2019-09-04 13:58:30 +02:00  (id:cli-ban-dummy-on-virt-141-lifetime-from)
>         Expression: date lt 2019-10-04 13:58:30 +02:00  (id:cli-ban-dummy-on-virt-141-lifetime-to)
>     Constraint: cli-ban-dummy-on-virt-142-first
>       Rule: boolean-op=and score=-INFINITY  (id:cli-ban-dummy-on-virt-142-first-rule)
>         Expression: #uname eq string virt-142  (id:cli-ban-dummy-on-virt-142-first-expr)
>         Expression: date lt 2019-09-04 14:02:32 +02:00  (id:cli-ban-dummy-on-virt-142-first-lifetime)
>     Constraint: cli-ban-dummy-on-virt-142-second
>       Rule: boolean-op=and score=-INFINITY  (id:cli-ban-dummy-on-virt-142-second-rule)
>         Expression: #uname eq string virt-142  (id:cli-ban-dummy-on-virt-142-second-expr)
>         Expression: date lt 2019-10-04 14:02:32 +02:00  (id:cli-ban-dummy-on-virt-142-second-lifetime)
> Ordering Constraints:
> Colocation Constraints:
> Ticket Constraints:
> [root@virt-141 ~]# date
> Wed Sep  4 13:59:17 CEST 2019


Test #1: non-existent rule ID

> [root@virt-141 ~]# crm_rule --check --rule nonexistent
> No rule found with ID=nonexistent containing a date_expression
> Error checking rule: No such device or address
> [root@virt-141 ~]# echo $?
> 105

Result: non-zero exit code, "no rule found" error message. Pass.


Test #2: rule without date expression

> [root@virt-141 ~]# crm_rule --check --rule ban-dummy-on-virt-142-forever-rule
> No rule found with ID=ban-dummy-on-virt-142-forever-rule containing a date_expression
> Error checking rule: No such device or address
> [root@virt-141 ~]# echo $?
> 105

Result: same non-zero exit code and error message as for non-existent rule. Slightly weird behavior ("No such device or address" for an existing rule ID), but good enough for an internal, experimental tool (for now). Pass.


Test #3: rule with multiple date expressions

> [root@virt-141 ~]# crm_rule --check --rule cli-ban-dummy-on-virt-141-rule
> More than one date_expression in cli-ban-dummy-on-virt-141-rule is not supported
> Error checking rule: Operation not supported
> [root@virt-141 ~]# echo $?
> 3

Result: unique & non-zero exit code, clear error message. Pass.


Test #4: standard ban constraint with lifetime, expired

> [root@virt-141 ~]# crm_rule --check --rule cli-ban-dummy-on-virt-142-first-rule
> Rule cli-ban-dummy-on-virt-142-first-rule is expired
> [root@virt-141 ~]# echo $?
> 110

Result: unique & non-zero exit code, rule correctly evaluated as expired. Pass.


Test #5: standard ban constraint with lifetime, still effective

> [root@virt-141 ~]# crm_rule --check --rule cli-ban-dummy-on-virt-142-second-rule
> Rule cli-ban-dummy-on-virt-142-second-rule is still in effect
> [root@virt-141 ~]# echo $?
> 0

Result: zero exit code, rule correctly evaluated as still in effect. Pass.


Test #6: standard ban constraint with lifetime, still effective now but checked against a future date

> [root@virt-141 ~]# crm_rule --check --rule cli-ban-dummy-on-virt-142-second-rule --date=2020-01-01
> Rule cli-ban-dummy-on-virt-142-second-rule is expired
> [root@virt-141 ~]# echo $?
> 110

Result: correct non-zero exit code and message as for an expired rule. Pass.


Test #7: standard ban constraint with lifetime, expired now but checked against a past date

> [root@virt-141 ~]# crm_rule --check --rule cli-ban-dummy-on-virt-142-first-rule --date=2010-01-01
> Rule cli-ban-dummy-on-virt-142-first-rule is still in effect
> [root@virt-141 ~]# echo $?
> 0

Result: correct zero exit code and message as for an effective rule. Pass.


Test #8: ban constraint with a date_spec

> [root@virt-141 ~]# crm_rule --check --rule ban-dummy-on-virt-142-cron-rule
> No rule found with ID=ban-dummy-on-virt-142-cron-rule containing a date_expression
> Error checking rule: No such device or address
> [root@virt-141 ~]# echo $?
> 105

Result: same non-zero exit code and error message as for non-existent rule. Rules containing date_spec are explicitly unsupported as per comment#8 (for now). See Test #2 for further comments. Pass.


(In reply to Ken Gaillot from comment #8)
> 1. Create a new CLI tool that accepts options for a timestamp (default now), a node name (defaulting to the local node), and a rule ID.

Node name option not present, but not required for implementing the requested functionality in pcs. Timestamp option works, as does specifying rule by its ID (with a small note in Test #2).

(In reply to Ken Gaillot from comment #8)
> 2. The tool would have exit status codes (besides errors) for "rule is in effect" (success i.e. 0) and "rule is not in effect".

Effective rules result in an exit code of 0, expired 110, unsupported 3 or 105 (see Test #2 again), non-existent 105.

(In reply to Ken Gaillot from comment #8)
> 3. The tool would print messages to stdout about whether the rule is in effect, and why not if not, with an option to create XML output instead (for reliable parsing by pcs and such). The initial implementation would check for the narrow "expired" case (rule has a single date_expression with an operation that is not "date_spec"). This output would be declared experimental and unsupported. pcs could rely on the behavior of the version in RHEL, but upstream and RHEL end users would be discouraged from using it until fully implemented.

No XML output option present (and IIUC not necessary for requested feature implementation in pcs). XML input is available, although not well documented. Reading the code reveals the "-X/--xml-text=value" option expects a CIB XML -- read either from stdin or as a string directly from argv, which is highly unusual (I'd expect it to accept a filename instead). This CIB XML, when specified, is used instead of connecting to the live CIB:

> [root@virt-141 ~]# pcs cluster cib > cib.xml
> [root@virt-141 ~]# systemctl stop pacemaker
> [root@virt-141 ~]# pcs status
> Error: cluster is not currently running on this node
> [root@virt-141 ~]# crm_rule --check --rule cli-ban-dummy-on-virt-142-second-rule -X - < cib.xml
> Rule cli-ban-dummy-on-virt-142-second-rule is still in effect


Marking verified in 2.0.2-3.el8.

--- Additional comment from Ken Gaillot on 2019-09-04 17:11:08 UTC ---

(In reply to Patrik Hagara from comment #13)
<snip>
> (In reply to Ken Gaillot from comment #8)
> > 1. Create a new CLI tool that accepts options for a timestamp (default now),
> > a node name (defaulting to the local node), and a rule ID.
> 
> The tool does not accept any node name. Not a huge issue, since the
> constraints themselves usually specify the target node's uname (eg. when
> created using "pcs resource move <rsc> lifetime=<iso8601-spec>", as per the
> original BZ request).

We decided to limit the scope of the initial implementation further -- I forgot to update the BZ, sorry.

As you saw, it also doesn't currently have an XML output option; we decided that the exit status codes were sufficient for pcs's use.
 
> > 2. The tool would have exit status codes (besides errors) for "rule is in
> > effect" (success i.e. 0) and "rule is not in effect".

For the record, besides errors, and success for "in effect", we added 110 for "expired", 111 for "not yet in effect", and 112 for "undetermined (rule is too complicated for current implementation)".

<snip>

> Looks like the CTS regression tests [1] for this feature are using
> nonsensical rules -- location constraints specifying only the lifetime, not
> the actual location (node) to avoid/prefer:

Good point, but the simplified form is sufficient to test the underlying implementation.

(In reply to Patrik Hagara from comment #15)
> Hm, looks like another UX issue...
> 
> The `pcs constraint` command displays "rsc_location" ID
> ("cli-ban-dummy-on-virt-142" in this case) and `crm_rule` expects the "rule"
> ID ("cli-ban-dummy-on-virt-142-rule", with "-rule" appended):

Another good point, but this is an artifact of mixing pcs and the pacemaker command-line. pcs will use this capability internally and might not directly expose it to the user, so it wouldn't need to show the user rule IDs in that case. If pcs does decide to expose it, presumably it would change the display accordingly.

In RHEL documentation we only document the pcs interfaces, to nudge users into using only that. If a user is using the pacemaker command-line tools, they are a more advanced user, and hopefully will learn the differences between the two approaches without too much pain.

--- Additional comment from Patrik Hagara on 2019-09-04 17:24:58 UTC ---

Thank you for mentioning the expected exit codes.

I missed one test case...


Test #9: ban constraint with start time in the future

> [root@virt-141 ~]# pcs constraint --full
> Location Constraints:
[...]
>     Constraint: cli-ban-dummy-on-virt-142-third
>       Rule: boolean-op=and score=-INFINITY  (id:cli-ban-dummy-on-virt-142-third-rule)
>         Expression: #uname eq string virt-142  (id:cli-ban-dummy-on-virt-142-third-expr)
>         Expression: date gt 2019-10-04 14:02:32 +02:00  (id:cli-ban-dummy-on-virt-142-third-lifetime)
> Ordering Constraints:
> Colocation Constraints:
> Ticket Constraints:
> [root@virt-141 ~]# crm_rule --check --rule cli-ban-dummy-on-virt-142-third-rule
> Rule cli-ban-dummy-on-virt-142-third-rule has not yet taken effect
> [root@virt-141 ~]# echo $?
> 111
> [root@virt-141 ~]# date
> Wed Sep  4 19:19:46 CEST 2019

Result: exit code and message matches expectations. Pass.


What concerns me now are the unexpected exit codes in test cases #1, #2, #3 and #8.