Bug 1572116
Summary: | Provide a CLI tool to check if specified rules / rule constraints are expired | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Tomas Jelinek <tojeline> | |
Component: | pacemaker | Assignee: | Chris Lumens <clumens> | |
Status: | CLOSED ERRATA | QA Contact: | cluster-qe <cluster-qe> | |
Severity: | medium | Docs Contact: | ||
Priority: | medium | |||
Version: | 8.0 | CC: | abeekhof, ableisch, aherr, cfeist, cluster-maint, cluster-qe, idevat, jruemker, kgaillot, mnovacek, obenes, omular, phagara, pzimek, rbeyel, sbradley, tojeline | |
Target Milestone: | rc | Keywords: | FutureFeature | |
Target Release: | 8.1 | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | pacemaker-2.0.2-1.el8 | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | ||
Clone Of: | 1442116 | |||
: | 1794850 (view as bug list) | Environment: | ||
Last Closed: | 2019-11-05 20:57:32 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1442116, 1546815, 1679810, 1759320, 1794850 |
Comment 1
Tomas Jelinek
2018-04-26 08:39:27 UTC
qa_ack+ New pacemaker CLI tool for viewing configured constraints and whether they are currently in effect (ie. not expired). This tool MUST NOT have any ability to modify the cluster configuration. After digging into this a little bit, it looks fairly complicated to fully check out a rule to see if it's expired or not. Rules can be nested and have boolean operators applied to their sub-rules. Some of the expressions can involve checking for a specific node or other site-specific information. In short, rules can be arbitrarily complicated and the code is difficult to unravel to fully simulate testing of a rule. I'm not even sure how feasible it is given the node restriction possibility. So what I'm wondering is: would you be okay with at least the initial implementation of this taking just a date_expression ID and testing that single node to see if it's expired? Alternately, I could perhaps make it to where it takes a rule ID, drills down to a single date_expression under that, and checks. But I don't really see a good way of testing more complex constraints than that. Perhaps afterwards, someone could improve upon this initial implementation. Sorry, I would not be ok with that. The whole point of this bz being filed against pacemaker is to have a rule evaluation engine implemented in pacemaker only, where it is implemented already anyway. Evaluating just date expressions in pacemaker leaving all the boolean operators and sub-rules to be evaluated in pcs is a complete opposite of that. I understand that evaluating rules is complicated and that related code in pacemaker may need major changes in order to implement the requested functionality. But I don't see that being a justification for re-implementing the rule evaluation engine in pcs. Doing so would bring new set of problems. It would require the two implementations to be working exactly the same, which brings another issues considering there is no strict relation between pcs and pacemaker versions. (In reply to Tomas Jelinek from comment #4) > Sorry, I would not be ok with that. > > The whole point of this bz being filed against pacemaker is to have a rule > evaluation engine implemented in pacemaker only, where it is implemented > already anyway. Evaluating just date expressions in pacemaker leaving all > the boolean operators and sub-rules to be evaluated in pcs is a complete > opposite of that. I understand that evaluating rules is complicated and that > related code in pacemaker may need major changes in order to implement the > requested functionality. But I don't see that being a justification for > re-implementing the rule evaluation engine in pcs. Doing so would bring new > set of problems. It would require the two implementations to be working > exactly the same, which brings another issues considering there is no strict > relation between pcs and pacemaker versions. The problem is not the mechanism of evaluation, but a lack of clarity in the desired goal. Pacemaker can determine a general solution to "in effect now, or not", but not "expired, or not". For example, consider a rule that's in effect from 9am-5pm weekdays on nodes whose "datacenter" attribute is "building2". Also, when rules are used with cluster properties or resource instance attributes, there can be multiple attribute blocks each with a rule, so even evaluating a complete (single) rule might not be a complete picture in that case. I think we are limited to these possibilities: - Given a single rule, return whether the rule is in effect on a specified node (defaulting to the local node) at a specified time (defaulting to now) (note: it is not possible in this case to detect "expired") - Given a single rule expression, return whether the expression is "in effect", "not in effect because expired", or "not in effect for some other reason" - Given either a cluster property, or a resource plus resource attribute, as well as a specified node (default local) and time (default now), return the evaluated value (by comparison, crm_attribute will currently return multiple matches if there are rules for a cluster property) ... none of which directly supports checking whether a constraint is expired. However, pcs doesn't necessarily need a general solution. If all pcs needs is to hide expired constraints, pcs could check each constraint for whether it had a single rule with a single expression, and if so, pass that expression ID to the new tool as suggested. I.e. pcs could hide the simple cases, and pass through everything else. OK, now I see what the issues is, thanks for explaining that out, Ken. The goal is that pcs displays expired constraints differently (mark them as expired or hide them, that does not really matter here). We want rule evaluation to be implemented in pacemaker only, not in pcs. Those are the main points. Perhaps the bz should have been named "... if specified rules / rule constraints are expired" instead. "Expired" and "in effect" are two very different statements, which was not obvious to me. Sorry for the confusion it created. At least it will be covered in this bz for future readers. So, what does "expired" mean? I would say it means a rule will never be in effect in the future. Meaning there is a date expression in the rule saying when the rule will not apply any more. According to this, from 9am-5pm weekdays on nodes whose "datacenter" attribute is "building2" never expires - there is no limiting date. Using cluster properties or resource instance attributes does not matter either, I think. It is perfectly possible that some day in future properties or attributes will be set so that a rule using them would be in effect, i.e. such rule also never expires. On the other hand, rules like "from 2018-12-01 to 2019-01-31" or "until 2019-01-31" clearly expire on the ending date. Now for combinations: "from 9am-5pm weekdays and from 2018-12-01 to 2019-01-31" - expires on the ending date "from 9am-5pm weekdays or from 2018-12-01 to 2019-01-31" - never expires, there will be plenty of weekdays after 2019-01-31 These are just simple combinations, actual rules may be much more complex than this. That, if I understand correctly, is the problem with deciding if they are expired. Giving that, I get now why you would like pcs to check what a rule looks like. How about this: * pcs would ask pacemaker if a rule is expired or not no matter what the rule looks like (i.e. pcs would always pass rule id to pacemaker) * pacemaker would check if it is capable to determine if the rule is expired based on its format / complexity * for the simple cases, pacemaker would mark the rule as expired or not * for other cases, pacemaker would mark the rule as not expired (or undecidable, perhaps) This would allow to keep all the logic in pacemaker and potentially improve / expand it in future without any changes needed in pcs. Also, it would keep the decisioning in pacemaker as simple as you originally proposed - we can start with simple rules with one expression and everything else would be marked by pacemaker as "undecidable". I guess this is pretty much in line with what is being implemented for bz1658650, isn't it? Deciding if a rule is in effect is a completely different task and I think there is no need to implement it now. Perhaps in the future, if someone requests it, there will be another tool for it. Or the tool for deciding expired rules could mark rules as (expired | not expired | don't know), (in effect | not in effect | don't know) - meaning it would give two distinctive flags to each rule. (In reply to Tomas Jelinek from comment #6) > "from 9am-5pm weekdays and from 2018-12-01 to 2019-01-31" - expires on the ending date Debatable; e.g. if the end date is a Saturday, does it expire at 11:59:59pm Saturday, or 5pm Friday? We even have that ridiculous "moon" option, so a rule could be e.g. "days with a full moon in 2019", and we'd have to figure out the last full moon of the year to know whether it's expired. Possible, but ugly. > marked by pacemaker as "undecidable". I guess this is pretty much in line > with what is being implemented for bz1658650, isn't it? That bz is much simpler -- it only has to deal with rules created by crm_resource, which uses a well-defined, narrow subset of the full rule syntax. A general solution is much more challenging. All existing code involves a simple pass/fail test of each rule component, so an "expired" determination would involve a significant rewrite. Looking at this more closely, the only simple case is a rule containing a single date_expression with an operation that is not "date_spec". I don't think I'd be comfortable releasing something that covers such a narrow case, and returning "undecidable" for everything else, with the meaning of that possibly changing over time. That seems a bit too fuzzy for the pacemaker CLI, which should be a definitive interface. I'm thinking this will have to drop in priority and get pushed to RHEL 8 only. I think we can follow this plan, in the RHEL 8.1 time frame: 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. 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". 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. 5. We could open a separate BZ for the full "why not" implementation, i.e. the ability to handle date_spec and multiple expressions, as well as reasons other than expired (e.g. in future, or node attribute does not match). The tool could also potentially be the home of a new option to fully evaluate any cluster property or resource parameter, a request that occasionally comes up -- current tools can only say what values are explicitly configured (possibly none or multiple), not what final value would be used at the moment (so, for example, there's currently no way to find out what the default of some property is). This is fixed by upstream commit fd91fd8e33b575810b03d2890de3ee23cb3b5e0e. 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 (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). > 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". Test #1: temporarily ban a resource from running on a particular node, use crm_rule to check whether it's still in effect > [root@virt-141 ~]# pcs resource move dummy lifetime=PT30M > Migration will take effect until: 2019-09-04 13:17:29 +02:00 > Warning: Creating location constraint 'cli-ban-dummy-on-virt-142' with a score of -INFINITY for resource dummy on virt-142. > This will prevent dummy from running on virt-142 until the constraint is removed > This will be the case even if virt-142 is the last node in the cluster > [root@virt-141 ~]# pcs constraint > Location Constraints: > Resource: dummy > Constraint: cli-ban-dummy-on-virt-142 > Rule: boolean-op=and score=-INFINITY > Expression: #uname eq string virt-142 > Expression: date lt 2019-09-04 13:17:29 +02:00 > Ordering Constraints: > Colocation Constraints: > Ticket Constraints: > [root@virt-141 ~]# crm_rule --check --rule cli-ban-dummy-on-virt-142 > No rule found with ID=cli-ban-dummy-on-virt-142 containing a date_expression > Error checking rule: No such device or address > [root@virt-141 ~]# echo $? > 105 Result: crm_rule is unable to check whether a simple lifetime ban constraint is still in effect. Since this was supposed to be the primary use-case for this new tool, I'm marking this as FailedQA. 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: > <constraints> > <rsc_location id="no-date-expression" rsc="dummy" score="-INFINITY" node="node01"/> > <rsc_location id="cli-prefer-dummy-expired" rsc="dummy"> > <rule id="cli-prefer-rule-dummy-expired" score="INFINITY"> > <date_expression id="cli-prefer-lifetime-end-dummy-expired" operation="lt" end=""/> > </rule> > </rsc_location> > <rsc_location id="cli-prefer-dummy-not-yet" rsc="dummy"> > <rule id="cli-prefer-rule-dummy-not-yet" score="INFINITY"> > <date_expression id="cli-prefer-lifetime-end-dummy-not-yet" operation="gt" start=""/> > </rule> > </rsc_location> > </constraints> For comparison, the `pcs resource move dummy lifetime=PT30M` command generated the following constraint: > <constraints> > <rsc_location id="cli-ban-dummy-on-virt-142" rsc="dummy" role="Started"> > <rule id="cli-ban-dummy-on-virt-142-rule" score="-INFINITY" boolean-op="and"> > <expression id="cli-ban-dummy-on-virt-142-expr" attribute="#uname" operation="eq" value="virt-142" type="string"/> > <date_expression id="cli-ban-dummy-on-virt-142-lifetime" operation="lt" end="2019-09-04 13:17:29 +02:00"/> > </rule> > </rsc_location> > </constraints> [1] https://github.com/ClusterLabs/pacemaker/pull/1691/files#diff-402ac06cbaaac9dc2a4c4fb1de754201 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): > [root@virt-141 ~]# crm_rule --check --rule cli-ban-dummy-on-virt-142-rule > Rule cli-ban-dummy-on-virt-142-rule is expired > [root@virt-141 ~]# date > Wed Sep 4 13:18:10 CEST 2019 > [root@virt-141 ~]# pcs constraint > Location Constraints: > Resource: dummy > Constraint: cli-ban-dummy-on-virt-142 > Rule: boolean-op=and score=-INFINITY > Expression: #uname eq string virt-142 > Expression: date lt 2019-09-04 13:17:29 +02:00 > Ordering Constraints: > Colocation Constraints: > Ticket Constraints: For reference, the constrains section from CIB: > <constraints> > <rsc_location id="cli-ban-dummy-on-virt-142" rsc="dummy" role="Started"> > <rule id="cli-ban-dummy-on-virt-142-rule" score="-INFINITY" boolean-op="and"> > <expression id="cli-ban-dummy-on-virt-142-expr" attribute="#uname" operation="eq" value="virt-142" type="string"/> > <date_expression id="cli-ban-dummy-on-virt-142-lifetime" operation="lt" end="2019-09-04 13:17:29 +02:00"/> > </rule> > </rsc_location> > </constraints> This is very confusing. Switching back to ON_QA and clearing FailedQA flag, as the UX issue is not that critical for an experimental tool to be used internally by pcs in the future. > [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. (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. 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. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3385 |