While I can see this being potentially confusing, it is intentional behavior, and consistent with how "pcs resource move" behaves without a lifetime. In both cases, it is expected that users will use "pcs resource clear" when they no longer want the constraints to be in the configuration.

The main reason is that the cluster never modifies the user's configuration without the user's involvement. Additionally, for troubleshooting purposes, a configuration can be saved and replayed later with a simulation using any given time -- an unlikely usage in this case, but supported.

We could reassign this to the pcs component, to have expired constraints displayed differently, maybe:

Location Constraints:
  Resource: Dummy
    Enabled on: node3 (score:INFINITY)
    Constraint (expired): cli-ban-Dummy-on-node1
      Rule: boolean-op=and score=-INFINITY
        Expression: #uname eq string node1
        Expression: date lt 2017-04-13 13:49:35Z
    Constraint (expired): cli-ban-Dummy-on-node2
      Rule: boolean-op=and score=-INFINITY
        Expression: #uname eq string node2
        Expression: date lt 2017-04-13 13:57:11Z
    Constraint (expired): cli-ban-Dummy-on-node3
      Rule: boolean-op=and score=-INFINITY
        Expression: #uname eq string node3
        Expression: date lt 2017-04-13 13:56:57Z

(In reply to Ken Gaillot from comment #2)
Hi Ken, 

thank you for the comment. Below is my reaction.

> While I can see this being potentially confusing, it is intentional
> behavior, and consistent with how "pcs resource move" behaves without a
> lifetime. In both cases, it is expected that users will use "pcs resource
> clear" when they no longer want the constraints to be in the configuration.

While 'pcs resource clear' will remove the constraint itself, we are only talking of it being displayed in the list of constraints after <lifetime> expires and the constraint itself is no longer effective.

By aligning 'pcs resource move' with lifetime to 'pcs resource move' without lifetime, you probably refer to the use of constraints, correct?



> The main reason is that the cluster never modifies the user's configuration
> without the user's involvement. 

The cluster puts that constraint in place on user's command, and cluster should remove the constraint from the list once it is no longer effective. This is what customers expect.

Re-assigning to pcs, as I believe this is a display issue with "pcs constraints".

I understand that the most intuitive expectation is that a constraint with a lifetime will "disappear" after that time expires, but that doesn't fit with key aspects of the pacemaker model. The cluster configuration is considered to be time-independent, and can be applied (in reality or a simulation) for any given timestamp. And the cluster never touches the part of the configuration that the user controls (aside from node attributes). Also consider the use case where a user configures a permanent constraint with a lifetime for administration windows, and just updates the times when needed.

So, I think the best solution is to make the expiration more prominent in the pcs command line and GUI.

Hi Ken,

Thank you for the explanation.

Could pcs team tell us their opinion?

Thanks
Ondrej

I agree with Ken.

Ken, is there a way to get pacemaker to tell whether a constraint is valid in a given time (now) or does this need to be (re)implemented in pcs?

Hi Ken, 

Have you had time to look at Tomas's earlier question yet? Thanks!

Regards,
Ondrej

(In reply to Tomas Jelinek from comment #7)
> I agree with Ken.
> 
> Ken, is there a way to get pacemaker to tell whether a constraint is valid
> in a given time (now) or does this need to be (re)implemented in pcs?

There's no tool, but there are C library functions from libcrmcommon and libpe_rules. This C function call will return TRUE if a date_expression XML block currently applies:

   test_date_expression(
      string2xml(date_expression_xml_as_string),
      crm_time_new(NULL)
   )

Hi Tomas, 

does Ken's reply help?

(In reply to Ondrej Benes from comment #10)
> Hi Tomas, 
> 
> does Ken's reply help?

Yes.

Pacemaker bz we depend on got moved to RHEL 8.

Is there any Plan to fix this in RHEL7.
We would like to use this feature, but at the moment its more confusing then to manually clear the constraint after a while

(In reply to Sandro from comment #18)
> Is there any Plan to fix this in RHEL7.
> We would like to use this feature, but at the moment its more confusing then
> to manually clear the constraint after a while

Sandro,

We are working to include this, but don't have an estimate for which release it will be included in.  If this is critical to your workflow please raise this issue with your support representative so we can properly prioritize this bug.

Fix merged into upstream master: https://github.com/ClusterLabs/pcs/commit/c4ea11228e851bf1076bb42c9a5536c8aa36922e

ENVIRONMENT PREPARATION:
- any cluster
- a dummy resource (pcs resource create dummy ocf:heartbeat:Dummy)

To test this fix, run commands:
# pcs constraint location dummy rule id=rule-valid score=INFINITY defined pingd
# pcs constraint location dummy rule id=rule-expired score=INFINITY date lt 2019-01-01
# pcs constraint
Location Constraints:
  Resource: dummy
    Constraint: location-dummy
      Rule: score=INFINITY
        Expression: defined pingd
Ordering Constraints:
Colocation Constraints:
Ticket Constraints:
# pcs constraint --all
Location Constraints:
  Resource: dummy
    Constraint: location-dummy
      Rule: score=INFINITY
        Expression: defined pingd
    Constraint (expired): location-dummy-1
      Rule (expired): score=INFINITY
        Expression: date lt 2019-01-01
Ordering Constraints:
Colocation Constraints:
Ticket Constraints:

After fix:

[root@r81-node-01 ~]# rpm -q pcs
pcs-0.10.3-1.el8.x86_64

[root@r81-node-01 pcs]# pcs constraint location d-01 rule id=rule-valid score=INFINITY defined pingd
[root@r81-node-01 pcs]# pcs constraint location d-01 rule id=rule-expired score=INFINITY date lt 2019-01-01
[root@r81-node-01 pcs]# pcs constraint
Location Constraints:
  Resource: d-01
    Constraint: location-d-01
      Rule: score=INFINITY
        Expression: defined pingd
Ordering Constraints:
Colocation Constraints:
Ticket Constraints:

This is not an issue in pcs. It is a limitation of a pacamaker tool. For more details see bz1572116#c8

Let me just note that [comment 25] introduced futile location
constraints.  While it does not invalidate anything for the testing
purposes, I thought it'd be good to point this out so that it doesn't
get used for anything serious.

In fact, it's unfortunate there's no push-back on such a bogus location
in the first place: https://bugs.clusterlabs.org/show_bug.cgi?id=5415

Thanks to Nina Hostakova for raising suspicion about usefulness
of such a form!

s/bogus location/bogus location constraint/
+ https://github.com/ClusterLabs/pcs/issues/235

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/RHEA-2020:1568