Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1063472 - fenceNode passes wrong argument to the fence agent
Summary: fenceNode passes wrong argument to the fence agent
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: vdsm
Version: 3.3
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: 3.4.0
Assignee: Dan Kenigsberg
QA Contact: Tareq Alayan
URL:
Whiteboard: infra
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-10 19:47 UTC by John Taylor
Modified: 2014-03-31 12:26 UTC (History)
9 users (show)

Fixed In Version: ovirt-3.4.0-beta3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-31 12:26:04 UTC
oVirt Team: ---


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 24303 None None None Never
oVirt gerrit 24343 None None None Never
oVirt gerrit 26075 None ABANDONED fencing: stop using a deprecated command Never

Description John Taylor 2014-02-10 19:47:34 UTC
Description of problem:
at least for ilo2, the power management status call (done by doing a test on the power managment setup for a host) causes a reboot instead of a status.



Version-Release number of selected component (if applicable):
ovirt 3.3.3 on fedora 19  (ovirt-engine-3.3.3-2.fc19)
hosts running on fedora 19 (vdsm-4.13.3-3.fc19)


How reproducible:
Always

Steps to Reproduce:
1. configure a 3.3 host with ilo2 power management
2. test the power management


Actual results:
the host will go into a reboot loop

Expected results:
power management status is confirmed OK without rebooting

Additional info:

in the vdsm logs of the host chosen as a proxy, there is the logging of the call to fenceNode

Thread-13969::DEBUG::2014-02-10 08:57:54,149::API::1110::vds::(fenceNode) fenceNode(addr=vm6-ilo.corp.sgstool.com,port=,agent=ilo,user=Administrator,passwd=XXXX,action=status,secure=,options=ssl=no)

and later the debug output that shows that "option=status" is ignored because it is not a valid option 

Thread-13969::DEBUG::2014-02-10 08:58:12,061::API::1136::vds::(fenceNode) rc 0 in agent=fence_ilo
ipaddr=vm6-ilo.corp.sgstool.com
login=Administrator
option=status
passwd=XXXX
ssl=no out Success: Rebooted
 err Parse error: Ignoring unknown option 'option=status'



It looks to me like the problem is that call in fenceNode (API.py line 1069) calls the agent with
        inp = ('agent=fence_%s\nipaddr=%s\nlogin=%s\noption=%s\n'
               'passwd=%s\n') % (agent, addr, username, action, password)


so that action param is passed as input parameter "option", instead of "action", this causes the default action to be performed instead, which is reboot

Comment 1 Dan Kenigsberg 2014-02-10 22:15:42 UTC
Which version of fence-agents do you have?

With fence-agents-3.1.5-35.el6.x86_64 a recent verification of the API.py code (post http://gerrit.ovirt.org/22997 ) succeeded:

Thread-21::DEBUG::2014-02-05 02:16:14,230::API::1126::vds::(fenceNode) fenceNode(addr=REMOVED.redhat.com,port=15,agent=apc_snmp,user=REMOVED,passwd=XXXX,action=off,secure=False,options=)
Thread-22::DEBUG::2014-02-05 02:16:14,230::utils::593::root::(execCmd) '/usr/sbin/fence_apc_snmp' (cwd None)
Thread-22::DEBUG::2014-02-05 02:16:15,923::utils::613::root::(execCmd) SUCCESS: <err> = ''; <rc> = 0
Thread-22::DEBUG::2014-02-05 02:16:15,924::API::1113::vds::(fence) rc 0 inp agent=fence_apc_snmp
ipaddr=REMOVED.redhat.com
login=REMOVED
option=off
passwd=XXXX
port=15
 out ['Success: Powered OFF'] err []

Comment 2 Dan Kenigsberg 2014-02-10 22:25:33 UTC
Yep, as reported in https://lists.fedorahosted.org/pipermail/cluster-commits/2013-February/003090.html v4.0.0 of fence-agents has removed the "option" we have depended upon.

I believe that a quick change would solve the issue for all supported platforms.

Comment 3 Dan Kenigsberg 2014-02-10 22:35:48 UTC
John, would you verify the posted patch?

Comment 4 John Taylor 2014-02-11 15:29:07 UTC
Hi Dan,
Yes, that patch fixes it. 
Thanks.

Comment 5 Tareq Alayan 2014-02-25 09:30:36 UTC
verified per comment 4

Comment 6 Sandro Bonazzola 2014-03-31 12:26:04 UTC
this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released


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