Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionJan Pokorný [poki]
2016-03-07 14:52:14 UTC
+++ This bug was initially created as a clone of Bug #1245721 +++
I don't think there is an "ask interactively" precedence in pcs
(putting auth aside), but in case of any resource running (or just
defined ... or just always) it would be good to ask the user if she
indeed wants "pcs cluster standby --all" or rather enable the maintenance
mode. Or just apply this logic without asking as this should definitely
be more sane thing to do.
--- Additional comment from Jan Pokorný on 2015-08-28 19:13:21 CEST ---
In case you don't like "standby --all" -> maintenance mode trigger
proposal, you may, at least, consider translating that command into
"pcs property set stop_all_resources=true" that would likely avoid
inevitable issue with iterated switch toggling -- evacuation
of the resources to the rest of living nodes (until they are
standby'd as well) connected with unnecessary and unhelpful
utilization peaks there (there are some risks implied).
[...]
--- Additional comment from Jan Pokorný on 2015-09-01 17:11:08 CEST ---
[...] I was talking about possibly bad behavior of "pcs cluster
standby --all" which could not be translated into enabling maintenance
mode as pcs hasn't be able to do that yet. With this bug resolved
it will be, hence proposing translating that command to maintenance
mode enablement (implicitly or explicitly). Is it more clear now?
Comment 1Jan Pokorný [poki]
2016-03-07 14:54:56 UTC
Promoting aside suggestion to an RFE on its own as it remained unheard.
Note that the equivalent sanity confirmation is relevant to both CLI
and GUI.
The "pcs cluster standby" command puts nodes into standby mode. It would be very counterintuitive and confusing if it did something else when --all flag was specified. And this would not be fixed by documenting such behavior. Also what if the user really wants to put all the nodes into standby mode? Is pcs so much clever than the user that it can deny him to do that? I do not think so.
You can argue that pcs could ask interactively what is it that the user really wants to do. But user must have typed the command in the first place, is not that a manifestation of desired action already? I think it is.
The issue with moving resources around cluster while putting several / all nodes into standby mode is already covered in bz1315992.
Therefore I am closing this as not a bug.