Description of problem:

When the --wait flag is used in pcs commands, pcs guesses in what state a resource managed by the command should be when the command finishes. At the end of the command, pcs checks in what state the resource really is and returns 0 if real and expected status matches or 1 if the statuses do not match.

The issue is the expected state of the resource is very hard to get right and that may lead to pcs exiting with a bad return code.

Version-Release number of selected component (if applicable):

pcs-0.9.158-4.el7.x86_64

How reproducible:

always, easily (depending on cluster settings complexity)

Steps to Reproduce:

pcs resource create test1 ocf:pacemaker:Dummy meta is-managed=false --wait
Error: resource 'test1' is not running on any node
echo $?
1

Actual results:

pcs exits with 1 because the resource did not start

Expected results:

pcs exits with 0 as the resource was not able to start (pacemaker does not start unmanaged resources) and therefore the command succeeded

Additional info:

With this particular reproducer the issue may seem to be easy to fix in pcs - if the resource is not managed, we expect it not to be started. However more complex setups are possible: the resource may not start due to constraints, utilization, cluster properties and so on and so forth. Also we are not talking about resource create only. Most of the commands supporting --wait are affected.