Bug 1420101 - generalize argument handling with commands like "resource delete": single operand -> multiple operands (-> pattern)
Summary: generalize argument handling with commands like "resource delete": single ope...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: pcs
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Tomas Jelinek
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On: 1315992 1420298
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-07 19:59 UTC by Jan Pokorný [poki]
Modified: 2020-12-01 07:28 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-01 07:28:10 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1420298 0 medium CLOSED "pcs resource delete" overhaul 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1420303 0 low CLOSED [man] make commands syntax description consistent 2021-02-22 00:41:40 UTC

Internal Links: 1420298 1420303

Description Jan Pokorný [poki] 2017-02-07 19:59:57 UTC
Having multiple resources configured (myres1, ... myres8),
I wanted to get rid of them all like this under bash session:

# pcs resource delete myres{1..8}
> Attempting to stop: myres1...Stopped

[note1: there's at least a single space missing to delimit the ellipsis]
[note2: consider also [bug 1225946 comment 7], point 8/, "excessive
        underdocumentation of where multiple arguments expected"]

That's pretty counter-productive behavior, it neither:
- deleted all specified resources, nor
- complained about the garbage provided at the end of what's
  considered a finalized command

So let me suggest a step, optionally two, as a way forward:

(0. optionally introduce new conventions for help screens to denote
    0-or-more-occurrences and 1-or-more-occurences, e.g., regexp
    inspired * and + postfix notation, and apply it for bigger
    brevity)

1. identify commands like "resource delete" that currently accepts,
   optionally or mandatorily, single specification of the operand
   and can be extended into multi-select without introducing new
   clashes with modifiers, key words of semantically different
   other operands, and apply such generalization

2. optionally, take another step, allow for wildcard or glob-like
   specification that will be matched against dynamically built
   pool of suitable identifiers/specifications;
   in my case from the beginning, I would just run:
   pcs resource delete myres\*

Systemd goes as far as step 2. in systemctl command, see PATTERN
in systemctl(1).

Comment 1 Ivan Devat 2017-02-08 07:03:02 UTC
I agree with adding the ability to delete multiple resources with a single "pcs resource delete". But I wouldn't go beyond. I guess it would carry unnecessary maintenance costs (even if we have module glob).

# pcs resource delete myres{1..8}
it may be replaced by
# echo myres{1..8}|xargs pcs resource delete

# pcs resource delete myres*
it may be replaced by
# pcs resource|awk '{print $1}'|grep ^myres|xargs resource delete

Currently it is possible to use a workaround:
# for i in myres{1..2}; do pcs resource delete $i ;done

Comment 2 Jan Pokorný [poki] 2017-02-08 08:46:44 UTC
Those workarounds miss the point.

I could as well use:

$ gcc -xc -o runx - <<EOF
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
  char buffer[1024];
  for (int i = 2; i < argc; i++) {
    snprintf(buffer, sizeof(buffer), "%s %s", argv[1], argv[i]);
    system(buffer);
  }
}
EOF

$ ./runx "pcs resource delete" myres{1..8}

One of the goals for pcs CLI shall be the intuitive (and presumably
uniform) convenience for the administrators.

Comment 3 Ivan Devat 2017-02-08 10:02:43 UTC
I understand and I strongly agree that the user experience is important. But each feature has its price and there are standard tools for such task. It is necessary to find a balance.

Your use case assumes a resource naming conventions. It could occur the (logical) requirement to delete all resources of the specific resource agent. Should we add such feature to "pcs resource delete"? I'd rather keep it simple when there is (relatively simple) possibility to use:

# pcs resource|grep ocf::heartbeat:Dummy|awk '{print $1}'|xargs pcs resource delete

Comment 4 Tomas Jelinek 2017-02-08 11:41:08 UTC
(In reply to Jan Pokorný from comment #0)
> Having multiple resources configured (myres1, ... myres8),
> I wanted to get rid of them all like this under bash session:
> 
> # pcs resource delete myres{1..8}
> > Attempting to stop: myres1...Stopped
> 
> [note1: there's at least a single space missing to delimit the ellipsis]
> [note2: consider also [bug 1225946 comment 7], point 8/, "excessive
>         underdocumentation of where multiple arguments expected"]
> 
> That's pretty counter-productive behavior, it neither:
> - deleted all specified resources, nor
> - complained about the garbage provided at the end of what's
>   considered a finalized command

This is a long-standing issue which we are aware of. A lot of pcs commands just ignore invalid or excessive parameters not informing the user at all. We are working on fixing this continuously as a part of moving all pcs commands to the new architecture. Pcs has a lot of commands, so it will take time to fix them all, but it will be done.

> 
> So let me suggest a step, optionally two, as a way forward:
> 
> (0. optionally introduce new conventions for help screens to denote
>     0-or-more-occurrences and 1-or-more-occurences, e.g., regexp
>     inspired * and + postfix notation, and apply it for bigger
>     brevity)
> 
> 1. identify commands like "resource delete" that currently accepts,
>    optionally or mandatorily, single specification of the operand
>    and can be extended into multi-select without introducing new
>    clashes with modifiers, key words of semantically different
>    other operands, and apply such generalization

We are aware of this as well. The same statement as above applies here.

Commands which can take more arguments but currently do not ("pcs resource delete" is a good example) often need to be overhauled to be able to make all the changes (i.e. deleting all the resources in this case) in one step (one push of the CIB). bz1315992 is an example that we are really working on this.

> 
> 2. optionally, take another step, allow for wildcard or glob-like
>    specification that will be matched against dynamically built
>    pool of suitable identifiers/specifications;
>    in my case from the beginning, I would just run:
>    pcs resource delete myres\*

This is not a bad idea. The priority however is to fix command line parameters parsing and allow specifying multiple parameters (i.e. resources to delete). Once that is done, it will be possible to add wildcards processing more easily than in the current situation.

> 
> Systemd goes as far as step 2. in systemctl command, see PATTERN
> in systemctl(1).


That being said I keep this bz open for tracking the progress.

Comment 5 Tomas Jelinek 2017-02-08 12:04:26 UTC
(In reply to Jan Pokorný from comment #0)
> (0. optionally introduce new conventions for help screens to denote
>     0-or-more-occurrences and 1-or-more-occurences, e.g., regexp
>     inspired * and + postfix notation, and apply it for bigger
>     brevity)

bz1420303

Comment 9 Tomas Jelinek 2017-03-13 13:26:42 UTC
Fixed commands:
* pcs node (un)maintenance
* pcs node (un)standby
* pcs resource enable, pcs resource disable

Comment 14 RHEL Program Management 2020-12-01 07:28:10 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.


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