Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1060672 - RHEVM-JAVA-SDK: VMCdRom.update(Boolean async, Boolean current, String correlationId) doesn't handle correctly null parameters.
Summary: RHEVM-JAVA-SDK: VMCdRom.update(Boolean async, Boolean current, String correl...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-sdk-java
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.3.1
Assignee: Juan Hernández
QA Contact: Ilia Meerovich
URL:
Whiteboard: infra
Depends On: 1047638
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-03 10:15 UTC by rhev-integ
Modified: 2016-07-05 00:07 UTC (History)
13 users (show)

Fixed In Version: rhevm-sdk-java-3.3.1.0-1.el6ev
Doc Type: Bug Fix
Doc Text:
Previously, methods that receive headers or URL paramters would add those headers or URL parameters to requests even if their value was null, causing command validation errors in some cases. Now, null headers and URL parameters are not added to requests.
Clone Of: 1047638
Environment:
Last Closed: 2014-02-27 09:32:37 UTC
oVirt Team: Infra


Attachments (Terms of Use)
java sdk debug output (deleted)
2014-02-20 07:26 UTC, Ilia Meerovich
no flags Details
engine log during failure (deleted)
2014-02-20 07:27 UTC, Ilia Meerovich
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:0217 normal SHIPPED_LIVE rhevm-sdk-java bug fix update 2014-02-27 14:32:06 UTC
oVirt gerrit 22947 None None None Never
oVirt gerrit 22996 None None None Never

Comment 2 Juan Hernández 2014-02-03 14:04:58 UTC
Moving back to MODIFIED as the complete RHEV build containing the fix hasn't been delivered to QE yet.

Comment 3 Eyal Edri 2014-02-05 09:15:10 UTC
moving to on_qa since we're releasing 3.3.1 is34

Comment 5 Ilia Meerovich 2014-02-19 09:56:37 UTC
I tested with ovirt-engine-sdk-java-3.4.0.4-1.el6.noarch. same result.

Comment 6 Juan Hernández 2014-02-19 13:06:05 UTC
I have tested this in a 3.3 environment, with the following versions:

# rpm -q rhevm
rhevm-3.3.1-0.48.el6ev.noarch
# rpm -q rhevm-sdk-java
rhevm-sdk-java-3.3.1.0-1.el6ev.noarch

And using the following test program (which is the same in the description, only changes in the values of the parameters):

public class SDKTest {
    private static final String URL = "https://rhel.example.com:443/api";
    private static final Boolean debug = true;
    private static final Boolean noHostVerifictaion = true;

    public static void main(String[] args) throws Exception {
        Api api = null;
        try {
            api = new Api(URL, "admin@internal", "***", null, null, null, null, noHostVerifictaion, null, debug);
            File file = new File();
            file.setId("rhel-server-6.4-x86_64-dvd.iso");
            VM myvm = api.getVMs().get("myvm");
            VMCdRom mycd = myvm.getCdRoms().list().get(0);
            mycd.setFile(file);
            mycd.update(null, true, null);
        }
        finally {
            if (api != null) {
                api.shutdown();
            }
        }
    }
}

This sends the following request to the server:

PUT /api/vms/c46bf225-4e58-48b8-bfac-112351b00619/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=ayX1gutOtYZ29ZsWqd1X8HvY

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cdrom href="/api/vms/c46bf225-4e58-48b8-bfac-112351b00619/cdroms/00000000-0000-0000-0000-000000000000" id="00000000-0000-0000-0000-000000000000">
    <vm href="/api/vms/c46bf225-4e58-48b8-bfac-112351b00619" id="c46bf225-4e58-48b8-bfac-112351b00619"/>
    <file id="rhel-server-6.4-x86_64-dvd.iso"/>
</cdrom>

And receives the following response:

HTTP/1.1 200 OK
Date: Wed, 19 Feb 2014 12:37:17 GMT
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 01:00:00 CET
Content-Type: application/xml
Content-Length: 365
Vary: Accept-Encoding
Connection: close

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cdrom href="/api/vms/c46bf225-4e58-48b8-bfac-112351b00619/cdroms/00000000-0000-0000-0000-000000000000" id="00000000-0000-0000-0000-000000000000">
    <vm href="/api/vms/c46bf225-4e58-48b8-bfac-112351b00619" id="c46bf225-4e58-48b8-bfac-112351b00619"/>
    <file id="rhel-server-6.4-x86_64-dvd.iso"/>
</cdrom>

The important thing to note is that the parameters of "update" method that are null aren't present in the request line, only "current=true" is present because the "current" parameter to the "update" method wasn't null. So, in these regards, the SDK works correctly.

I also verified that the virtual machine had the CD changed, I connected to that machine and mounted the CDROM after running the test, and it worked correctly.

I suggest to test this again with 3.3. If it fails in the QE environment then we will need more information about the failure (server logs), as it will probably be a different issue. That probably deserves a new bug.

Tested also connecting to the same 3.3 server with the upstream SDK 3.4:

# rpm -q ovirt-engine-sdk-java
ovirt-engine-sdk-java-3.4.0.4-1.fc20.noarch

The result is the same, so I'm reasonably confident the the issue in the SDK is solved.

Comment 7 Martin Pavlik 2014-02-19 13:25:30 UTC
> I suggest to test this again with 3.3. If it fails in the QE environment then we > will need more information about the failure (server logs), as it will probably > be a different issue. That probably deserves a new bug.

Ilia can you please provide requested information?

Comment 8 Ilia Meerovich 2014-02-19 13:37:43 UTC
I'm using local dc with one host and local iso domain. (and maybe it is an issue root cause - local iso domain)
When I will my 3.3 setup back I will retest it.

Comment 9 Ilia Meerovich 2014-02-20 07:25:53 UTC
I tested it with 3.3 setup:
imeerovi@imeerovi ~/git/ART (RHEVM-979-dc-search) $ rpm -q rhevm-sdk-java
rhevm-sdk-java-3.3.1.0-1.el6ev.noarch

Code:
package java_sdk_testing;

import org.ovirt.engine.sdk.Api;

public class JavaSDKTestDebug {
	private static final String URL = "https://ilia-rhevm.qa.lab.tlv.redhat.com:443/api";
	private static final Boolean debug = true; 
	private static final Boolean noHostVerifictaion = true;

	public static void main(String[] args) throws Exception {
		Api api = new Api(URL, "admin@internal", "123456", null, null, null, null, noHostVerifictaion, null, debug);
		File file = new File();
		file.setId("rhev-tools-setup.iso");
		VM vm = api.getVMs().list().get(0);
		VMCdRom cdrom = vm.getCdRoms().list().get(0);
		cdrom.setFile(file);
		cdrom.update(null, true, null);
		api.shutdown();
	}
}


Rhevm setup:
[root@ilia-rhevm ~]# rpm -q rhevm
rhevm-3.3.1-0.47.el6ev.noarch

I have:
-local DC
-local Cluster
-host (vdsm-4.13.2-0.11.el6ev.x86_64)
-local data domain
-defaut nfs iso domain that rhevm exposes (in my previous attempts I used local iso domain but since I put there iso files manually due to a bug in rhevm-iso-uploader (I did it according to iso uploader code but it is still hack so I wanted to repro it with default iso domain))
-vm (just created it, in down state, no disk, no vnic)


Scenario: just run the above code. 
I'm attaching sdk log and engine log. It seems that engine doesn't handle well last sdk put request

Comment 10 Ilia Meerovich 2014-02-20 07:26:38 UTC
Created attachment 865354 [details]
java sdk debug output

Comment 11 Ilia Meerovich 2014-02-20 07:27:30 UTC
Created attachment 865355 [details]
engine log during failure

Comment 12 Juan Hernández 2014-02-20 11:22:12 UTC
The problem is that when the VM is down we can't change the CD, however we don't check this in the canDoAction method of the ChangeDiskCommand. The net result is that when we try to find the host in order to send the command to VDSM we call get(null) on a hash map, and that generates a NPE.

Comment 13 Juan Hernández 2014-02-20 12:26:18 UTC
I have created bug 1067407 to track the problem in the backend. As the problem in the Java SDK is already solved I think we can move this bug to ON_QA, and eventually to VERIFIED.

Comment 14 Juan Hernández 2014-02-20 13:33:31 UTC
I'm moving to verified because the SDK isn't sending the parameters that are not null, and the backend issue is a different issue. Ilia, if you think this isn't correct please move it back to ASSIGNED.

Comment 17 errata-xmlrpc 2014-02-27 09:32:37 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/RHBA-2014-0217.html


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