Created attachment 844148 [details] vdsm.log Description of problem: hook: after_update_device_fail failed to run due to problems with setLinkAndNetwork function on vm.py module. see attached vdsm.log Steps to Reproduce: 1. add some script to /usr/libexec/vdsm/hooks/after_update_device_fail/ that does something e.g "touch /var/tmp/somefile". 2. set permission for the script, CHMOD 755. 3. Invoke the hook. I did: a) edit a working vm's nic, put LinkState - down. b) update fails. Actual results: hook is invoked but fails to perform it's task and the script does not run. vdsm.log produces this error: Thread-7625::DEBUG::2014-01-01 15:46:36,253::vm::3267::vm.Vm::(setLinkAndNetwork) vmId=`bcdf626c-88ac-4c83-bfc8-822692 d7a213`::Rolling back link and net for: net0 Traceback (most recent call last): File "/usr/share/vdsm/vm.py", line 3261, in setLinkAndNetwork hooks.after_update_device_fail(vnicStrXML, self.conf, custom) File "/usr/share/vdsm/hooks.py", line 246, in after_update_device_fail raiseError=False, params=params) File "/usr/share/vdsm/hooks.py", line 64, in _runHooksDir env_update = [params.iteritems(), AttributeError: 'NoneType' object has no attribute 'iteritems' Thread-7625::ERROR::2014-01-01 15:46:36,290::BindingXMLRPC::1003::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 989, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 284, in vmUpdateDevice return vm.vmUpdateDevice(params) File "/usr/share/vdsm/API.py", line 390, in vmUpdateDevice return v.updateDevice(params) File "/usr/share/vdsm/vm.py", line 3314, in updateDevice return self._updateInterfaceDevice(params) File "/usr/share/vdsm/vm.py", line 3218, in _updateInterfaceDevice custom, specParams): File "/usr/lib64/python2.6/contextlib.py", line 16, in __enter__ return self.gen.next() File "/usr/share/vdsm/vm.py", line 3261, in setLinkAndNetwork hooks.after_update_device_fail(vnicStrXML, self.conf, custom) File "/usr/share/vdsm/hooks.py", line 246, in after_update_device_fail raiseError=False, params=params) File "/usr/share/vdsm/hooks.py", line 64, in _runHooksDir env_update = [params.iteritems(), AttributeError: 'NoneType' object has no attribute 'iteritems' Expected results: uppon failure of the update, the hook should invoke the script we wrote and /var/tmp/somefile should be created. Additional info:
seems to be related to the parameters that are sent by engine to vmUpdateDevice command more than to the hooking infra. Dan, I see its part of setLinkAndNetwork flow. can you take a look ?
Correct, Yaniv. Sefi, could you help me verify the posted patch?
Sefi, which version of Engine was used for this reproduction? If it was rhev-m-3.0, this bug may be a GA blocker as it would effectively kill rfe bug 893576.
it was tested on rhevm-3.3.0-0.42.el6ev.noarch.rpm
Thanks for the information, Tareq. It means that my commit message for http://gerrit.ovirt.org/22922 was wrong, and even rhevm-3.3 sends no "custom" entry when it has nothing to populate it with. Nonetheless, this is not a blocker bug. It affects only people who install an after_update_device hook, and do not set any custom property for their vnic. Until 3.3.1, such users can circumvent the bug by removing the after_update_device hook, or setting a dummy custom property in all of their vnic profiles.
Verified on RHEL 6.5 , ovirt 3.4.0-0.7.beta2 Steps to Reproduce: 1. add some script to /usr/libexec/vdsm/hooks/after_update_device_fail/ that does something e.g "touch /var/tmp/somefile". 2. set permission for the script, CHMOD 755. 3. Invoke the hook. I did: a) vdsClient -s rose07.qa.lab.tlv.redhat.com vmUpdateDevice 976cea23-3cc8-43bc-9b8f-b26269534af8 deviceType=interface alias=net0 network=giasfkasf b) update fails. 4. /var/tmp/somefile found.
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/RHBA-2014-0504.html