Red Hat Bugzilla – Bug 959879
[REST-API] Update of power management by sending entire host representation is ignored
Last modified: 2016-02-10 14:32:09 EST
Created attachment 744006 [details] update_ip.cli Description of problem: Unable update power management fields via cli, just enable disable option is work. Version-Release number of selected component (if applicable): sf15 How reproducible: Add host to engine, add some power management, try to update some field via cli. Steps to Reproduce: 1. Add host to engine 2. Add some power management(not necessary to be with correct address) 3. Try to update some field of power management via CLI Actual results: No update Expected results: Updated field Additional info: Attach log with trying to update host power management ip from 10.1.1.1 to 10.10.10.10
Artyom, as you can see (in attached cli log) cli sends <address>10.10.10.10</address>, but engine ignores it, please attach engine log.
Created attachment 744015 [details] engine.log
Looks like the reason the power management host address is not updated is because we are checking for status of the power management host before updating it. In case the new host is not in UP status we are not updating the power management information. Below is the relevant log, is there a reason we should update the power management information even if the proxy host is down (or invalid power management host)? 2013-05-06 09:50:33,138 ERROR [org.ovirt.engine.core.bll.FenceExecutor] (ajp-/127.0.0.1:8702-6) [2e23dd59] Failed to run Power Management command on Host cyan-vdsf.qa.lab.tlv.redhat.com, no running proxy Host was found.
(In reply to comment #3) > Looks like the reason the power management host address is not updated is > because we are checking for status of the power management host before > updating it. In case the new host is not in UP status we are not updating > the power management information. Below is the relevant log, is there a > reason we should update the power management information even if the proxy > host is down (or invalid power management host)? not sure we can even if we want (as we might have no connectivity to the host), but engine should trigger a can-do-action error in such case instead of silently ignoring the update, simon? > > 2013-05-06 09:50:33,138 ERROR [org.ovirt.engine.core.bll.FenceExecutor] > (ajp-/127.0.0.1:8702-6) [2e23dd59] Failed to run Power Management command on > Host cyan-vdsf.qa.lab.tlv.redhat.com, no running proxy Host was found.
In the UI it is possible to update the power management information of the host even if the power management address is not reachable , this action will result with alert . One more thing: since power management cards are quite common / essential it is import to fix this bug soon , preferably to this version ( rc ) .
This is a duplicate of 3.3 bug 950684
*** This bug has been marked as a duplicate of bug 950684 ***
(In reply to Ravi Nori from comment #6) > This is a duplicate of 3.3 bug 950684 ravi, can you please explain why this bug is a dup of bug 950684?
*** Bug 949599 has been marked as a duplicate of this bug. ***
The reason the update command fails is because we are retrieving the host from the server, updating the host with the new powermanagement information and then calling update with the new object. A lot of unnecessary data gets sent to the RestAPI. The fix for the bug 950684 also fixes the issue we have here. In other works the patch for bug 950684 fixes the issue that has been reported in this bug.
(In reply to Ravi Nori from comment #10) > The reason the update command fails is because we are retrieving the host > from the server, updating the host with the new powermanagement information > and then calling update with the new object. A lot of unnecessary data gets > sent to the RestAPI. The fix for the bug 950684 also fixes the issue we have > here. In other works the patch for bug 950684 fixes the issue that has been > reported in this bug. it's not fixes it, but hides it, if one will do the same [1] in api, he will face exactly the same problem, i.e if we support PATCH over PUT, it doesn't mean we should not support pure PUT [1]. [1] take the resource, change what you need and PUT it as is
Created attachment 751346 [details] PUT xml The xml currently sent from cli contains all the information about VDS (host). The xml also contains power_management->agents information. In HostMapper we are first setting power_management->address to VdsStatic.ManagementIp and then loop through agents and over write the VdsStatic.ManagementIp with agent.address. I think currently cli sends a lot of unnecessary information which is causing the issue reported in the bug. I can change the order in which HostMapper is setting the values to resolve this issue, but it could lead to other issues. I still think the right way to fix this is to send only the required amount of information from cli.
(In reply to Ravi Nori from comment #12) > Created attachment 751346 [details] > PUT xml > > The xml currently sent from cli contains all the information about VDS > (host). The xml also contains power_management->agents information. In > HostMapper we are first setting power_management->address to > VdsStatic.ManagementIp and then loop through agents and over write the > VdsStatic.ManagementIp with agent.address. I think currently cli sends a lot > of unnecessary information which is causing the issue reported in the bug. > > I can change the order in which HostMapper is setting the values to resolve > this issue, but it could lead to other issues. I still think the right way > to fix this is to send only the required amount of information from cli. what you describing is supporting only PATCH, this is inconsistent with the rest of the api, where we support both PUT & PATCH, also this is logically incorrect, user should be able to GET resource representation (from the api), change what he wants and PUT it back to server as is (i.e entire representation, not only the part that has been changed).
Verification failed on is13: using the same scenario from https://bugzilla.redhat.com/show_bug.cgi?id=949599#c3 [RHEVM shell (connected@10.35.161.51)]# update host 'rose03' --storage_manager-priority 5 --power_management-username 'user' --power_management-address '10.35.35.35' --power_management-enabled true --power_management-password 'password' --power_management-type 'bladecenter' --power_management-options-option "option.name=secure,option.value=false,option.name=slot,option.value=1" --correlation_id 103 id : 615d14c4-9c57-4615-ab49-0a0908f7faea name : rose03 cluster-id : cd46a665-6e33-484f-acc5-04330d4dfede libvirt_version-build : 2 libvirt_version-full_version : libvirt-0.10.2-18.el6_4.9 libvirt_version-major : 0 libvirt_version-minor : 10 libvirt_version-revision : 0 port : 54321 power_management-address : 10.35.35.35 power_management-agents-agent-address : 10.35.35.35 power_management-agents-agent-options-option-name : secure power_management-agents-agent-options-option-value: false power_management-agents-agent-options-option-name : slot power_management-agents-agent-options-option-value: 1 power_management-agents-agent-order : 1 power_management-agents-agent-type : bladecenter power_management-agents-agent-username : user power_management-enabled : True power_management-options-option-name : secure power_management-options-option-value : false power_management-options-option-name : slot power_management-options-option-value : 1 power_management-type : bladecenter power_management-username : user version-full_version : vdsm-4.12.0-105.git0da1561.el6ev version-major : 4 version-minor : 12 [RHEVM shell]# update host rose03 --storage_manager-priority 5 --power_management-enabled true --power_management-type 'rsa' --correlation_id 104 id : 615d14c4-9c57-4615-ab49-0a0908f7faea name : rose03 cluster-id : cd46a665-6e33-484f-acc5-04330d4dfede libvirt_version-full_version : libvirt-0.10.2-18.el6_4.9 libvirt_version-major : 0 libvirt_version-minor : 10 libvirt_version-revision : 0 power_management-address : 10.35.35.35 power_management-agents-agent-address : 10.35.35.35 power_management-agents-agent-options-option-name : secure power_management-agents-agent-options-option-value: false power_management-agents-agent-options-option-name : slot power_management-agents-agent-options-option-value: 1 power_management-agents-agent-order : 1 power_management-agents-agent-type : bladecenter power_management-agents-agent-username : user power_management-enabled : True power_management-options-option-name : secure power_management-options-option-value : false power_management-options-option-name : slot power_management-options-option-value : 1 power_management-type : bladecenter power_management-username : user version-full_version : vdsm-4.12.0-105.git0da1561.el6ev version-major : 4 version-minor : 12
(In reply to Barak Dagan from comment #14) > Verification failed on is13: > > using the same scenario from > https://bugzilla.redhat.com/show_bug.cgi?id=949599#c3 > [RHEVM shell (connected@10.35.161.51)]# update host 'rose03' > --storage_manager-priority 5 --power_management-username 'user' > --power_management-address '10.35.35.35' --power_management-enabled true > --power_management-password 'password' --power_management-type 'bladecenter' > --power_management-options-option > "option.name=secure,option.value=false,option.name=slot,option.value=1" > --correlation_id 103 collection based option ^ is not correct, you've used twice same properties in the --power_management-options-option help is: ======== COLLECTION BASED OPTION FORMAT * [--x-y: collection] { [y.a: string] [y.b: string] [y.c: string] } e.g: --x-y "y.a=a1,y.b=b1,y.c=c1" --x-y "y.a=a2,y.b=b2,y.c=c2" ... i.e it should be: ================ --power_management-options-option "option.name=secure,option.value=false" --power_management-options-option "option.name=slot,option.value=1"
Thanks for explaining how to use the collections, however that part worked. The second part of changing the type from bladecenter to rsa is the part that failed.
Verified on is15: [RHEVM shell]# show host rose03 id : 615d14c4-9c57-4615-ab49-0a0908f7faea name : rose03 cluster-id : cd46a665-6e33-484f-acc5-04330d4dfede ... power_management-address : 10.35.35.35 power_management-agents-agent-address : 10.35.35.35 power_management-agents-agent-options-option-name : secure power_management-agents-agent-options-option-value: false power_management-agents-agent-options-option-name : slot power_management-agents-agent-options-option-value: 1 power_management-agents-agent-order : 1 power_management-agents-agent-type : bladecenter power_management-agents-agent-username : user power_management-enabled : True power_management-options-option-name : secure power_management-options-option-value : false power_management-options-option-name : slot power_management-options-option-value : 1 power_management-type : bladecenter [RHEVM shell# update host rose03 --storage_manager-priority 5 --power_management-enabled true --power_management-type 'rsa' --correlation_id 104 id : 615d14c4-9c57-4615-ab49-0a0908f7faea name : rose03 cluster-id : cd46a665-6e33-484f-acc5-04330d4dfede ... libvirt_version-build : 2 libvirt_version-full_version : libvirt-0.10.2-18.el6_4.9 libvirt_version-major : 0 libvirt_version-minor : 10 libvirt_version-revision : 0 ... power_management-address : 10.35.35.35 power_management-agents-agent-address : 10.35.35.35 power_management-agents-agent-options-option-name : secure power_management-agents-agent-options-option-value: false power_management-agents-agent-options-option-name : slot power_management-agents-agent-options-option-value: 1 power_management-agents-agent-order : 1 power_management-agents-agent-type : rsa power_management-agents-agent-username : user power_management-enabled : True power_management-options-option-name : secure power_management-options-option-value : false power_management-options-option-name : slot power_management-options-option-value : 1 power_management-type : rsa
This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag. Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information: * Cause: What actions or circumstances cause this bug to present. * Consequence: What happens when the bug presents. * Fix: What was done to fix the bug. * Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore') Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug. For further details on the Cause, Consequence, Fix, Result format please refer to: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks in advance.
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-2014-0038.html