Bug 1442116
Summary: | ban constraint remains in constraint list when lifetime parameter is used even after ban expires | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Josef Zimek <pzimek> | |
Component: | pcs | Assignee: | Michal Pospisil <mpospisi> | |
Status: | CLOSED ERRATA | QA Contact: | cluster-qe <cluster-qe> | |
Severity: | unspecified | Docs Contact: | Steven J. Levine <slevine> | |
Priority: | medium | |||
Version: | 8.0 | CC: | ableisch, cfeist, cluster-maint, hbarcomb, idevat, jpokorny, jruemker, kgaillot, lmanasko, michele.sandro.emma, mlisik, nhostako, obenes, omular, rbeyel, sbradley, slevine, tojeline | |
Target Milestone: | rc | Keywords: | FutureFeature | |
Target Release: | 8.2 | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
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.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1572116 1759320 (view as bug list) | Environment: | ||
Last Closed: | 2020-04-28 15:27:56 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: | 1572116, 1682129 | |||
Bug Blocks: | 1546815, 1679810, 1759320 |
Description
Josef Zimek
2017-04-13 14:48:49 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. 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 |