Bug 1522813

Summary: Traceback when creating a stonith resource with --wait
Product: Red Hat Enterprise Linux 7 Reporter: Patrik Hagara <phagara>
Component: pcsAssignee: Tomas Jelinek <tojeline>
Status: CLOSED ERRATA QA Contact: cluster-qe <cluster-qe>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 7.5CC: aherr, cfeist, cluster-maint, idevat, omular, rsteiger, tojeline
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pcs-0.9.162-2.el7 Doc Type: Bug Fix
Doc Text:
Cause: The user creates a stonith resource and uses the --wait option in the command. Consequence: The resource is created and pcs crashes in waiting for the resource to start. Fix: Call the function for waiting for resources to start with correct parameters. Result: Pcs creates the stonith resource and waits for it to start.
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 15:40:54 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:
Attachments:
Description Flags
proposed fix + test none

Description Patrik Hagara 2017-12-06 13:56:20 UTC
Description of problem:
The command "pcs stonith create [...] --wait" fails with a traceback (the stonith resource does get created/started correctly):

> # pcs stonith create foo fence_xvm --wait
> Traceback (most recent call last):
>   File "/usr/sbin/pcs", line 9, in <module>
>     load_entry_point('pcs==0.9.162', 'console_scripts', 'pcs')()
>   File "/usr/lib/python2.7/site-packages/pcs/app.py", line 208, in main
>     cmd_map[command](argv)
>   File "/usr/lib/python2.7/site-packages/pcs/stonith.py", line 46, in stonith_cmd
>     stonith_create(lib, argv_next, modifiers)
>   File "/usr/lib/python2.7/site-packages/pcs/stonith.py", line 191, in stonith_create
>     **settings
>   File "/usr/lib/python2.7/site-packages/pcs/cli/common/lib_wrapper.py", line 97, in decorated_run
>     return run_with_middleware(run, cli_env, *args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/pcs/cli/common/middleware.py", line 19, in run
>     return next_in_line(env, *args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/pcs/cli/common/middleware.py", line 42, in apply
>     result_of_next = next_in_line(env, *args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/pcs/cli/common/middleware.py", line 68, in apply
>     result_of_next = next_in_line(env, *args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/pcs/cli/common/lib_wrapper.py", line 87, in run
>     lib_call_result = run_library_command(lib_env, *args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/pcs/lib/commands/stonith.py", line 75, in create
>     resource.common.disable(stonith_element)
>   File "/usr/lib64/python2.7/contextlib.py", line 24, in __exit__
>     self.gen.next()
>   File "/usr/lib/python2.7/site-packages/pcs/lib/commands/resource.py", line 47, in resource_environment
>     for res_id in wait_for_resource_ids
> TypeError: 'bool' object is not callable
> # echo $?
> 1
> # pcs stonith 
>  foo	(stonith:fence_xvm):	Started virt-267

Version-Release number of selected component (if applicable):
pcs-0.9.162-1.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. "pcs stonith create [...] --wait"

Actual results:
pcs fails with the above traceback, while the fencing resource is correctly created and started

Expected results:
no traceback, wait until stonith resource is created/started

Additional info:

Comment 2 Tomas Jelinek 2017-12-07 14:39:19 UTC
Created attachment 1364336 [details]
proposed fix + test

Comment 3 Ivan Devat 2017-12-12 08:49:26 UTC
After Fix:

[ant ~] $ rpm -q pcs pcs-snmp
pcs-0.9.162-2.el7.x86_64
pcs-snmp-0.9.162-2.el7.x86_64

[ant ~] $ pcs stonith create F fence_xvm pcmk_host_list="ant bee" --wait
resource 'F' is running on node 'ant'
[ant ~] $ echo $?
0

Comment 9 errata-xmlrpc 2018-04-10 15:40:54 UTC
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/RHBA-2018:0866