When using perl scripts using the REST-api to manipulate VMs. One can notice the following difference in behaviour between versions 3.2 and 3.3 of RHEVM. To create a VM one uses POST to put the xml payload to URL /api/vms. If there is a need for it to be synchronous, then add "expect 201-created" header. In 3.2 this POST call takes *11 seconds* and the resulting xml contains status "down", meaning the custom_software can "start" the VM. In 3.3 this POST call takes 1 second and the resulting xml contains status "locked" and an additional creation_status "pending", meaning that one cannot "start" the VM. In the release 3.3 notes there is no mention of this change. Which API calls are affected in RHEV-3.3 as compared to 3.2? This needs to be documented.
I think that the problem is that in we actually remove the Expect header from requests, so whatever the caller sends is completely ignored. We explicitly remove it, with the following web server configuration in /etc/httpd/conf.d/z-ovirt-engine.conf: <IfModule headers_module> RequestHeader unset Expect early </IfModule> We do this because the web server doesn't support the Expect header unless it has the 100-continue value. The value that we use to specify blocking operation is 201-created, and that causes the following web server response: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>417 Expectation Failed</title> </head><body> <h1>Expectation Failed</h1> <p>The expectation given in the Expect request-header field could not be met by this server. The client sent<pre> Expect: 201-created </pre> </p><p>Only the 100-continue expectation is supported.</p> </body></html> This should happen in 3.2 as well, unless they were connecting to the application server directly, not via the web server. Can you confirm this? If this is the case then I would suggest, as a temporary workaround, to do the same in 3.3.
I just noticed that the application server is also swallowing the Expect header, so the workaround proposed in comment 2 won't work. I'm checking if this changed in a recent version of the application server.
I have to correct myself, I didn't test this correctly. The expect header is not swallowed by the application server. So the workaround described in comment 2 (connect directly to the application server) does work. Please ask the customer to try it, and report the results.
The proposed patch changes the RESTAPI so that it will accept the old Expect header and a new X-Ovirt-Expect one. Both have the same meaning, but the new one isn't rejected by the web server. To preserve backwards compatibility users are encouraged to send both headers, with the same value, for example: POST /ovirt-engine/api/vms HTTP/1.1 ... Expect: 201-created X-Ovirt-Expect: 201-created The first will be removed by the web server, but the second will reach the application server and have the expected effect.
Verified. I tried to create a vm, add a disk to it (so the operation would take significant time) and then start it, all this in a script using REST API. Without using headers '-H "Expect: 201-created" -H "X-Ovirt-Expect: 201-created"' the operation failed. When I used the headers, operation took longer to finish and succeeded. oVirt Engine Version: 3.5.0-0.0.master.20140821064931.gitb794d66.el6
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. https://rhn.redhat.com/errata/RHSA-2015-0158.html