Bug 1047638
Summary: | RHEVM-JAVA-SDK: VMCdRom.update(Boolean async, Boolean current, String correlationId) doesn't handle correctly null parameters. | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Ilia Meerovich <iliam> | ||||||
Component: | ovirt-engine-sdk-java | Assignee: | Juan Hernández <juan.hernandez> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Ondra Machacek <omachace> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 3.3.0 | CC: | aberezin, adahms, bazulay, eedri, iheim, juan.hernandez, oramraz, pstehlik, talayan, yeylon | ||||||
Target Milestone: | --- | Keywords: | ZStream | ||||||
Target Release: | 3.4.0 | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | infra | ||||||||
Fixed In Version: | rhevm-sdk-java-3.4.0.1-0.1.el6_5 | Doc Type: | Bug Fix | ||||||
Doc Text: |
Previously, methods in the Java SDK that accept header or URL arguments would fail under certain conditions. This was caused by the logic in those methods, which would add those arguments to requests even when the values of the arguments were null. Now, this logic has been revised so that arguments with null values are not added to requests, allowing commands to be processed correctly.
|
Story Points: | --- | ||||||
Clone Of: | |||||||||
: | 1060672 (view as bug list) | Environment: | |||||||
Last Closed: | 2014-06-09 14:16:10 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 1060672, 1078909, 1142926 | ||||||||
Attachments: |
|
Description
Ilia Meerovich
2014-01-01 12:31:57 UTC
I meant engine log (not jboss server log) reproduced with ovirt-engine-sdk-java-3.4.0.3-0.1.el6.noarch Steps for reproduction: Setup: 1. datacenter, cluster, host (I worked with local storage domain configuration) 2. data domain and iso domain with iso file inside it. Steps: 1. Create VM 2. run the above code' and you will get this exception: Exception in thread "main" code : 500 reason: Internal Server Error detail: General command validation failure. at org.ovirt.engine.sdk.web.HttpProxy.execute(HttpProxy.java:118) at org.ovirt.engine.sdk.web.HttpProxyBroker.update(HttpProxyBroker.java:104) at org.ovirt.engine.sdk.decorators.VMCdRom.update(VMCdRom.java:151) at java_sdk_testing.JavaSDKTestDebug.main(JavaSDKTestDebug.java:20) with this trace in engine log - attached and looks similar to original one Created attachment 858240 [details]
ovirt-engine log
This was fixed in the rhevm-sdk-java-3.4.0.1-0.1 downstream build, and also in the ovirt-engine-sdk-java-3.4.0.3-1 upstream build available here: http://jhernand.fedorapeople.org/rpms/ovirt-engine-sdk-java/3.4.0.3-1 Note that you tested with 3.4.0.3-0.1, not with 3.4.0.3-1. This bug should be fixed in ovirt-3.4.0-beta3 but it has already a fixed-in-version set and is in state modified instead of ON_QA. Assignee please fix the bug status and consider adding a reference to ovirt 3.4.0 release notes page if relevant. Eyal, has an official build containing this fix already been delivered to QE? If so, can we move to ON_QA? QE got AV1 build with includes a newer pkg of rhevm-sdk so i think you can move to ON_QA. http://bob.eng.lab.tlv.redhat.com/builds/latest_av/av1_version_info.html Created attachment 876041 [details]
engine.log
Don't work for me with rhevm-sdk-java-3.4.0.7.jar
Created java class which is in description.
CLASSPATH=$CLASSPATH:usr/share/java/rhevm-sdk-java/rhevm-sdk-java-3.4.0.7.jar:httpcomponents-client-4.3.3/lib/httpclient-4.3.3.jar javac my/JavaSDKTestDebug.java
CLASSPATH=$CLASSPATH:usr/share/java/rhevm-sdk-java/rhevm-sdk-java-3.4.0.7.jar:httpcomponents-client-4.3.3/lib/*:slf4j-1.7.6/*:apache-log4j-2.0-rc1-bin/log4j-api-2.0-rc1.jar:apache-log4j-1.2.17/*:commons-beanutils-1.9.1/* java my.JavaSDKTestDebug
Exception in thread "main"
code : 500
reason: Internal Server Error
detail: General command validation failure.
at org.ovirt.engine.sdk.web.HttpProxy.execute(HttpProxy.java:118)
at org.ovirt.engine.sdk.web.HttpProxyBroker.update(HttpProxyBroker.java:104)
at org.ovirt.engine.sdk.decorators.VMCdRom.update(VMCdRom.java:196)
at my.JavaSDKTestDebug.main(JavaSDKTestDebug.java:20)
This bug is about making sure that the SDK doesn't send to the server the parameters which values are null. In order to verify it you need to make sure that the generated PUT request is as follows: PUT /api/vms/9f8be70b-bd6d-44ea-91c8-d89c0aee3dbe/cdroms/00000000-0000-0000-0000-000000000000;current=true HTTP/1.1 Content-type: application/xml Filter: false Prefer: persistent-auth Content-Length: 365 Host: rhel.example.com:443 Connection: Keep-Alive User-Agent: Apache-HttpClient/4.2.1-redhat-1 (java 1.5) Cookie: JSESSIONID=8E2yWPL8WghvfbWtmVfgMrb0.undefined ... The important thing here is that the request must have the "current=true" URL parameter and it mustn't have the "async=null" URL parameter or the "Correlation-id: null" header. If that is ok then this bug is fixed. The 500 error code that you are getting is a different issue, a server side one, reported in bug 1067407, caused by a NPE when trying to change the current CD for a VM that is down. Please check this again with a VM that is up. 2014-03-20 14:57:45,641 DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Sending request: PUT /api/vms/dc3444d6-00b9-450c-aa17-b56bd0835105/cdroms/00000000-0000-0000-0000-000000000000;current=true HTTP/1.1 2014-03-20 14:57:45,641 DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: PUT /api/vms/dc3444d6-00b9-450c-aa17-b56bd0835105/cdroms/00000000-0000-0000-0000-000000000000;current=true HTTP/1.1 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] >> "PUT /api/vms/dc3444d6-00b9-450c-aa17-b56bd0835105/cdroms/00000000-0000-0000-0000-000000000000;current=true HTTP/1.1[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] (main) >> "PUT /api/vms/dc3444d6-00b9-450c-aa17-b56bd0835105/cdroms/00000000-0000-0000-0000-000000000000;current=true HTTP/1.1[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] >> "Content-type: application/xml[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] (main) >> "Content-type: application/xml[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] >> "Filter: false[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] (main) >> "Filter: false[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] >> "Prefer: persistent-auth[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] (main) >> "Prefer: persistent-auth[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] >> "Content-Length: 364[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] (main) >> "Content-Length: 364[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] >> "Host: 10.34.63.30:443[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] (main) >> "Host: 10.34.63.30:443[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] (main) >> "Connection: Keep-Alive[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] >> "User-Agent: Apache-HttpClient/4.3.3 (java 1.5)[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] (main) >> "User-Agent: Apache-HttpClient/4.3.3 (java 1.5)[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] >> "Cookie: JSESSIONID=FN1GUadk5rKoCUOW9v3Y5wBt[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] (main) >> "Cookie: JSESSIONID=FN1GUadk5rKoCUOW9v3Y5wBt[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] >> "Cookie2: $Version=1[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] (main) >> "Cookie2: $Version=1[\r][\n]" 2014-03-20 14:57:45,642 DEBUG [org.apache.http.wire] >> "[\r][\n]" 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/RHEA-2014-0663.html |