This limitation was considered acceptable for the initial implementation due to the complexity of date-spec. However, I think we should easily be able to handle cases where "years" is specified, and "moon" is not. We can focus this BZ on that particular case.

For a date-spec without "years", there's really no expiration since it's recurring (monthly or whatever). I think the current behavior is acceptable in that case.

The "moon" option (0-7 where 0 is the new moon and 4 is the full moon) was more of a (somewhat ridiculous) demonstration of what was possible than a useful option. I think for practical reasons, we can leave expiration checking unimplemented when "moon" is used with "years", which hopefully is never. Perhaps we should even deprecate "moon" and eventually remove it.

This is pretty straightforward.  I'm finishing up a PR now, but want to run it through some additional tests before I send it off for review.  I'm hoping to do that at the beginning of next week.

https://github.com/ClusterLabs/pacemaker/pull/1982

Fixed upstream as of https://github.com/ClusterLabs/pacemaker/pull/1982

qa_ack+, reproducer in description

Tested on a basic 2-node cluster.

Before fix:
>[root@virt-036 ~]# rpm -q pacemaker
>pacemaker-2.0.3-5.el8_2.1.x86_64
>[root@virt-036 ~]# pcs resource create "Dummy" ocf:pacemaker:Dummy
>[root@virt-036 ~]# pcs constraint location Dummy rule date-spec years=2018
>[root@virt-036 ~]# pcs constraint --full | sed "s/^/\[`date +"%Y-%m-%d %H:%M:%S"`] /"
>[2020-08-04 14:42:18] Location Constraints:
>[2020-08-04 14:42:18]   Resource: Dummy
>[2020-08-04 14:42:18]     Constraint: location-Dummy
>[2020-08-04 14:42:18]       Rule: score=INFINITY (id:location-Dummy-rule)
>[2020-08-04 14:42:18]         Expression: (id:location-Dummy-rule-expr)
>[2020-08-04 14:42:18]           Date Spec: years=2018 (id:location-Dummy-rule-expr-datespec)
>[2020-08-04 14:42:18] Ordering Constraints:
>[2020-08-04 14:42:18] Colocation Constraints:
>[2020-08-04 14:42:18] Ticket Constraints:
>[root@virt-036 ~]# crm_rule --check --rule location-Dummy-rule
>No rule found with ID=location-Dummy-rule containing a date_expression
>Error checking rule: No such device or address
>[root@virt-036 ~]# echo $?
>105

Result: Constraints containing date-spec rules are not evaluated so they remain in the constraint list after expiration

After fix:
>[root@virt-128 ~]# rpm -q pacemaker
>pacemaker-2.0.4-5.el8.x86_64
>[root@virt-128 ~]# pcs resource create "Dummy" ocf:pacemaker:Dummy
>[root@virt-128 ~]# pcs constraint location Dummy rule date-spec years=2018
>[root@virt-128 ~]# pcs constraint --full | sed "s/^/\[`date +"%Y-%m-%d %H:%M:%S"`] /"
>[2020-08-04 15:27:41] Location Constraints:
>[2020-08-04 15:27:41] Ordering Constraints:
>[2020-08-04 15:27:41] Colocation Constraints:
>[2020-08-04 15:27:41] Ticket Constraints:
>[root@virt-128 ~]# crm_rule --check --rule location-Dummy-rule
>Rule location-Dummy-rule is expired
>[root@virt-128 ~]# echo $?
>110

Result: Constraints containing date-spec rules are evaluated and they dont remain in the constraint list after expiration.

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 (pacemaker bug fix and enhancement update), 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/RHEA-2020:4804