Bug 1442116 - ban constraint remains in constraint list when lifetime parameter is used even after ban expires
Summary: ban constraint remains in constraint list when lifetime parameter is used eve...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: pcs
Version: 8.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: 8.2
Assignee: Michal Pospisil
QA Contact: cluster-qe@redhat.com
Steven J. Levine
URL:
Whiteboard:
Depends On: 1572116 1682129
Blocks: 1546815 1679810 1759320
TreeView+ depends on / blocked
 
Reported: 2017-04-13 14:48 UTC by Josef Zimek
Modified: 2023-03-24 13:48 UTC (History)
18 users (show)

Fixed In Version: pcs-0.10.3-1.el8
Doc Type: Enhancement
Doc Text:
.Expired resource constraints are now hidden by default when listing constraints Listing resource constraints no longer by default displays expired constraints. To include expired constaints, use the `--all` option of the `pcs constraint` command. This will list expired constraints, noting the constraints and their associated rules as `(expired)` in the display.
Clone Of:
: 1572116 1759320 (view as bug list)
Environment:
Last Closed: 2020-04-28 15:27:56 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3038031 0 None None None 2018-08-07 13:20:27 UTC
Red Hat Product Errata RHEA-2020:1568 0 None None None 2020-04-28 15:28:35 UTC

Description Josef Zimek 2017-04-13 14:48:49 UTC
Description of problem:

This command creates temporary ban constraint on node1 for resource Dummy (expected):

node1# pcs resource move Dummy lifetime=10S

After lifetime period expires the ban is still listed in constraint list (and every new move with lifetime adds new one):

`pcs constraint`

Location Constraints:
  Resource: Dummy
    Enabled on: node3 (score:INFINITY)
    Constraint: 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: 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: 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



Once the ban expires the constraint is still listed in constraint list


Version-Release number of selected component (if applicable):
RHEL 7.3
pacemaker-1.1.15-11.el7.x86_64



Actual results:

* The ban constraint remains listed in constraints list after expiration


Expected results:

* Expired ban constraint is not listed in the list



Additional info:

* Current list is confusing for customers especially when they use "move" with "lifetime" parameter often they need to remove old inactive constraints from the list manually

Comment 2 Ken Gaillot 2017-04-17 14:22:06 UTC
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.

Comment 3 Ken Gaillot 2017-04-17 14:23:29 UTC
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

Comment 4 Ondrej Benes 2017-05-10 15:14:26 UTC
(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.

Comment 5 Ken Gaillot 2017-05-10 15:42:58 UTC
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.

Comment 6 Ondrej Benes 2017-05-18 08:51:28 UTC
Hi Ken,

Thank you for the explanation.

Could pcs team tell us their opinion?

Thanks
Ondrej

Comment 7 Tomas Jelinek 2017-05-18 10:44:39 UTC
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?

Comment 8 Ondrej Benes 2017-06-19 08:36:18 UTC
Hi Ken, 

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

Regards,
Ondrej

Comment 9 Ken Gaillot 2017-06-19 14:24:29 UTC
(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)
   )

Comment 10 Ondrej Benes 2017-07-11 06:03:43 UTC
Hi Tomas, 

does Ken's reply help?

Comment 11 Tomas Jelinek 2017-07-11 08:33:24 UTC
(In reply to Ondrej Benes from comment #10)
> Hi Tomas, 
> 
> does Ken's reply help?

Yes.

Comment 17 Tomas Jelinek 2019-01-09 15:29:23 UTC
Pacemaker bz we depend on got moved to RHEL 8.

Comment 18 Sandro 2019-01-29 14:42:56 UTC
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

Comment 19 Chris Feist 2019-02-05 23:45:32 UTC
(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.

Comment 25 Michal Pospisil 2019-10-02 12:51:48 UTC
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:

Comment 26 Miroslav Lisik 2019-10-23 15:37:48 UTC
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:

Comment 31 Ondrej Mular 2019-12-18 11:31:10 UTC
This is not an issue in pcs. It is a limitation of a pacamaker tool. For more details see bz1572116#c8

Comment 33 Jan Pokorný [poki] 2019-12-18 15:35:19 UTC
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!

Comment 34 Jan Pokorný [poki] 2019-12-18 15:52:11 UTC
s/bogus location/bogus location constraint/
+ https://github.com/ClusterLabs/pcs/issues/235

Comment 41 errata-xmlrpc 2020-04-28 15:27:56 UTC
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


Note You need to log in before you can comment on or make changes to this bug.