Moving back to MODIFIED as the complete RHEV build containing the fix hasn't been delivered to QE yet.

moving to on_qa since we're releasing 3.3.1 is34

I tested with ovirt-engine-sdk-java-3.4.0.4-1.el6.noarch. same result.

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.

> 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?

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.

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

Created attachment 865354 [details]
java sdk debug output

Created attachment 865355 [details]
engine log during failure

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.

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.

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.

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