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

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.

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

(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.

(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

Fixed commands:
* pcs node (un)maintenance
* pcs node (un)standby
* pcs resource enable, pcs resource disable

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.