Bug 835478 - 3.1 - Add Execcmd to RHEV3.0 / VDSM
3.1 - Add Execcmd to RHEV3.0 / VDSM
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vdsm (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Dan Kenigsberg
Tareq Alayan
Depends On:
Blocks: 835606
  Show dependency treegraph
Reported: 2012-06-26 05:57 EDT by Tomas Von Veschler
Modified: 2012-12-04 14:00 EST (History)
11 users (show)

See Also:
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)
Last Closed: 2012-12-04 14:00:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomas Von Veschler 2012-06-26 05:57:05 EDT
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:


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@server7.selab.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>
  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

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 06:40:02 EDT
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 11:05:41 EDT
expose hooking.execCmd and use it in hook scripts

Comment 4 Igor Lvovsky 2012-07-01 05:22:53 EDT
Just check that you are able to run hooks for 3.1 and 3.0
Comment 8 Oded Ramraz 2012-11-28 07:57:03 EST
Moving to verified per comment7
Comment 10 errata-xmlrpc 2012-12-04 14:00:46 EST
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.


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