+++ This bug was initially created as a clone of Bug #2178707 +++ Description of problem: Pcs does not warn the user that he is entering the wrong data format for the location rule, he can then see the constraint in the cluster and gets no information that it might not work. Version-Release number of selected component (if applicable): [root@virt-508 ~]# pcs --version 0.10.14 Steps to Reproduce: 1. pcs constraint location dummy rule score=INFINITY date lt '01-01-2022' Actual results: Command passes and I can see location in the cluster Expected results: pcs warns the user that they are entering the wrong data format and returns an error code
Already reported and fixed upstream: https://github.com/ClusterLabs/pcs/pull/644 Upstream patch: https://github.com/ClusterLabs/pcs/commit/a346c30c11744c0d3f9126b4456f0d13e51848bc Test: # pcs constraint location dummy rule date lt '01-01-2022' Error: 'date lt 01-01-2022' is not a valid rule expression: '01-01-2022' is not an ISO 8601 date
DevTestResults: [root@r09-03-a ~]# rpm -q pcs pcs-0.11.5-1.el9.x86_64 [root@r09-03-a ~]# pcs constraint location r1 rule date lt '01-01-2022' Error: 'date lt 01-01-2022' is not a valid rule expression: '01-01-2022' is not an ISO 8601 date
## BEFORE [root@virt-248 ~]# rpm -q pcs pcs-0.11.4-6.el9.x86_64 [root@virt-248 ~]# pcs resource create d1 ocf:heartbeat:Dummy [root@virt-248 ~]# echo $? 0 [root@virt-248 ~]# pcs resource * d1 (ocf:heartbeat:Dummy): Started virt-248 A). Entering invalid date format for location rule (not an ISO 8601 date) [root@virt-248 ~]# pcs constraint location d1 rule date lt 22-06-2023 [root@virt-248 ~]# echo $? 0 [root@virt-248 ~]# pcs constraint location config Location Constraints: Resource: d1 Constraint: location-d1 Rule: score=INFINITY Expression: date lt 22-06-2023 > In the previous version it was possible to specify a constraint rule with a date whose format was not correct (not an ISO8601 date format). This case did not return an error and the return code was 0. ## AFTER [root@virt-019 ~]# rpm -q pcs pcs-0.11.5-2.el9.x86_64 [root@virt-019 ~]# pcs resource create d1 ocf:heartbeat:Dummy [root@virt-019 ~]# echo $? 0 [root@virt-019 ~]# pcs resource * d1 (ocf:heartbeat:Dummy): Started virt-018 A.) Entering invalid date format(dd-mm-yyyy, not an ISO 8601 date) [root@virt-019 ~]# pcs constraint location d1 rule date lt 22-06-2023 Error: 'date lt 22-06-2023' is not a valid rule expression: '22-06-2023' is not an ISO 8601 date [root@virt-019 ~]# echo $? 1 [root@virt-019 ~]# pcs constraint location config > OK. B.) Entering another invalid date format (yyyy/month/dd) [root@virt-019 ~]# pcs constraint location d1 rule date lt 06/22/2023 Error: 'date lt 06/22/2023' is not a valid rule expression: '06/22/2023' is not an ISO 8601 date [root@virt-019 ~]# echo $? 1 [root@virt-019 ~]# pcs constraint location config > OK. C.) Entering US date format (mm/dd/yyyy, not an ISO 8601 date) [root@virt-019 ~]# pcs constraint location d1 rule date lt 06/22/2023 Error: 'date lt 06/22/2023' is not a valid rule expression: '06/22/2023' is not an ISO 8601 date [root@virt-019 ~]# echo $? 1 [root@virt-019 ~]# pcs constraint location config > OK. D.) Entering invalid date format (yyyy-mm/dd) [root@virt-019 ~]# pcs constraint location d1 rule date lt 2023-06/23 [root@virt-019 ~]# echo $? 0 [root@virt-019 ~]# pcs constraint location config > I am not sure about validity of this edge case. The first part of the date is OK and so it is possible that it is evaluated as a valid ISO 8601 date, but in this case the user is not notified that this date is an invalid date format. Also there is no warning/error message and it returns with 0 return code, however no actie location constraint is displayed. [root@virt-019 ~]# pcs constraint location config --all Location Constraints: resource 'd1' Rules: Rule (expired): score=INFINITY Expression: date lt 2023-06/23 [root@virt-019 ~]# date Wed Jun 21 03:36:08 PM CEST 2023 > This location constraint rule is shown as expired even though it should not be expired yet. We have created a new BZ that addresses this issue (https://bugzilla.redhat.com/show_bug.cgi?id=2216492) E.) Entering invalid date format (yyyy/mm-dd) [root@virt-019 ~]# pcs constraint location d1 rule lt 2023/06-23 Error: 'lt 2023/06-23' is not a valid rule expression: unexpected 'lt' [root@virt-019 ~]# echo $? 1 [root@virt-019 ~]# pcs constraint location config > OK. F.) Entering valid ISO8601 basic date format [root@virt-019 ~]# pcs constraint location d1 rule date lt 2023-06-22 [root@virt-019 ~]# echo $? 0 [root@virt-019 ~]# pcs constraint location config Location Constraints: resource 'd1' Rules: Rule: score=INFINITY Expression: date lt 2023-06-22 > OK. G.) Entering valid ISO8601 week date format [root@virt-019 ~]# pcs constraint location d1 rule date lt 2023-W25-4 [root@virt-019 ~]# echo $? 0 [root@virt-019 ~]# pcs constraint location config Location Constraints: resource 'd1' Rules: Rule: score=INFINITY Expression: date lt 2023-W25-4 > OK. H.) Entering valid ISO8601 date format [root@virt-019 ~]# pcs constraint location d1 rule date lt 2023-173 [root@virt-019 ~]# echo $? 0 [root@virt-019 ~]# pcs constraint location config Location Constraints: resource 'd1' Rules: Rule: score=INFINITY Expression: date lt 2023-173 > OK. I.) Entering more complex valid date expression [root@virt-019 ~]# pcs constraint location d1 rule date in_range 2023-01-01 to 2023-175 [root@virt-019 ~]# echo $? 0 [root@virt-019 ~]# pcs constraint location config Location Constraints: resource 'd1' Rules: Rule: score=INFINITY Expression: date in_range 2023-01-01 to 2023-175 > OK. > Overall, working with dates that are specified in ISO 8601 standard works reliably. However, in my opinion, it would be useful to add an extra check to ensure that only ISO 8601 dates are supported. This is addressed in (https://bugzilla.redhat.com/show_bug.cgi?id=2216492). > Marking as VERIFIED for pcs-0.11.5-2.el9.x86_64