Bug 835478

Summary: 3.1 - Add Execcmd to RHEV3.0 / VDSM
Product: Red Hat Enterprise Linux 6 Reporter: Tomas Von Veschler <tvvcox>
Component: vdsmAssignee: Dan Kenigsberg <dkenigsb>
Status: CLOSED ERRATA QA Contact: Tareq Alayan <talayan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.2CC: abaron, acathrow, bazulay, cpelland, danken, iheim, ilvovsky, jbiddle, oramraz, yeylon, ykaul
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: vdsm-4.9.6-18.0 Doc Type: Bug Fix
Doc Text:
Previously, the improved hooks mechanism for 3.1 could not work on 3.0 implementations of Red Hat Enterprise Virtualization. The hooks mechanism has now been changed so that hooks written for 3.1 can work on 3.0.
Story Points: ---
Clone Of:
: 835606 (view as bug list) Environment:
Last Closed: 2012-12-04 19:00:46 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:
Bug Depends On:    
Bug Blocks: 835606    

Description Tomas Von Veschler 2012-06-26 09:57:05 UTC
Description of problem:

Changes in hooks mechanism to work on future versions (like Ovirt 3.1) are not working on RHEV 3.0 anymore. Compatibility of hook scripts should be kept or will make them difficult to implement and upgrade. In this case execCMD is missing.

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

RHEV 3.0

How reproducible:

Always

Steps to Reproduce:
1. Download hooks from ovirt repository:

$ git clone git://gerrit.ovirt.org/vdsm.git 

2. Try to use it on RHEV 3.0, for example: directlun, hostusb, sriov:

$ scp before_vm_start.py root.mad.redhat.com:/usr/libexec/vdsm/hooks/before_vm_start/50_directlun
$ rhevm-config -s UserDefinedVMProperties='directlun=3600144f0e90c870000004d4194ed001f' --cver=3.0
$ service jbossas restart

3. Assign a VM with the custom property: directlun=3600144f0e90c870000004d4194ed001f

4. Run the VM

Actual results:

Failed to run VM

Expected results:

VM runs, hook works

Additional info:

Thread-801844::DEBUG::2012-06-26 07:24:02,872::utils::579::Storage.Misc.excCmd::(execCmd) '/usr/libexec/vdsm/hooks/before_vm_start/50_directlun' (cwd None)
Thread-801844::DEBUG::2012-06-26 07:24:02,956::utils::579::Storage.Misc.excCmd::(execCmd) FAILED: <err> = 'directlun: [unexpected error]: Traceback (most recent call last):\n  File "/usr/libexec/vdsm/hooks/before_vm_start/50_directlun", line 130, in <module>\n    createDirectory(DEV_DIRECTLUN_PATH)\n  File "/usr/libexec/vdsm/hooks/before_vm_start/50_directlun", line 73, in createDirectory\n    retcode, out, err = hooking.execCmd(command, sudo=True, raw=True)\nAttributeError: \'module\' object has no attribute \'execCmd\'\n\n'; <rc> = 2
Thread-801844::INFO::2012-06-26 07:24:02,958::hooks::51::root::(_runHooksDir) directlun: [unexpected error]: Traceback (most recent call last):
  File "/usr/libexec/vdsm/hooks/before_vm_start/50_directlun", line 130, in <module>
    createDirectory(DEV_DIRECTLUN_PATH)
  File "/usr/libexec/vdsm/hooks/before_vm_start/50_directlun", line 73, in createDirectory
    retcode, out, err = hooking.execCmd(command, sudo=True, raw=True)
AttributeError: 'module' object has no attribute 'execCmd'


Thread-801844::DEBUG::2012-06-26 07:24:02,958::vm::357::vm.Vm::(_startUnderlyingVm) vmId=`243e7a14-b266-44d6-9148-e8b437cbb5e6`::_ongoingCreations released
Thread-801844::ERROR::2012-06-26 07:24:02,959::vm::381::vm.Vm::(_startUnderlyingVm) vmId=`243e7a14-b266-44d6-9148-e8b437cbb5e6`::The vm start process failed
Traceback (most recent call last):
  File "/usr/share/vdsm/vm.py", line 347, in _startUnderlyingVm
  File "/usr/share/vdsm/libvirtvm.py", line 1076, in _run
  File "/usr/share/vdsm/hooks.py", line 69, in before_vm_start
  File "/usr/share/vdsm/hooks.py", line 61, in _runHooksDir
HookError


Comments from Dan Kenigsberg:

we need to ship a hooking.py with execCmd
to rhev-3.0.z. This requires a BZ and the agreement of qe and pm.

Comment 1 Dan Kenigsberg 2012-06-26 10:40:02 UTC
I think this bug is description is way too broad.

I thought that what bothers our SAs is the change of upstream - and I
think you cannot impose such a constraint on upstream vdsm.

Even 3.0/3.1 hook compatibility, we *know* that it cannot be
acomplished: for example, 3.1 is going ot have cpu pinning custom
propert out of the box. People that use the pincpu hook would most
probably have to remove it.

I also do not know of a nice way to keep `from utils import execCmd`
working on 3.1. I was looking for a more specific bug - "expose
hooking.execCmd and use it in hook scripts".

Comment 2 Dan Kenigsberg 2012-06-26 15:05:41 UTC
expose hooking.execCmd and use it in hook scripts

http://gerrit.ovirt.org/5616

Comment 4 Igor Lvovsky 2012-07-01 09:22:53 UTC
Just check that you are able to run hooks for 3.1 and 3.0

Comment 8 Oded Ramraz 2012-11-28 12:57:03 UTC
Moving to verified per comment7

Comment 10 errata-xmlrpc 2012-12-04 19:00:46 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.

http://rhn.redhat.com/errata/RHSA-2012-1508.html