possible 3.4.1 blocker

Hi, please review this bug report: I can't boot this vm via cloud init, this worked before, it causes an unhandled exception in jboss: https://bugzilla.redhat.com/show_bug.cgi?id=1093755 I'm aware I may have an error in my json syntax as this got changed from 3.3.x to 3.4.x . I tried to keep up with the changes and hope I got everything right. So please correct my json, or if it is correct please help me debug while this raises an exception. I believe I'm one of not too many people (maybe the only one?) who tests cloud-init via REST/json so maybe I hit a bug. Thanks for your help in advance. PS: Here again the json for lazy people who don't want to click links ;) {"vm":{"initialization":{"cloud_init":{"host":{"address":"test"},"network_configuration":{"nics":{"nics":[{"name":"eth0","boot_protocol":"STATIC","network":{"ip":{"address":"10.211.0.236","netmask":"255.255.255.248","gateway":"10.211.0.233"}},"on_boot":true}]},"dns":{"servers":{"hosts":[{"address":"46.30.62.99"},{"address":"46.30.62.98"},{"address":"46.30.62.97"}]}}},"users":{"users":[{"name":"root","password":"#9Dh2--3xz-h95Zy"}]},"files":{"files":[{"name":"\/foo\/test","content":"test","type":"PLAINTEXT"}]}}}}} -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

Am 02.05.2014 17:05, schrieb Sven Kieske:
May I ask what the point of RC testing is, when discovered regressions get retargeted for the next release? I thought the policy was to not release something with a known regression? This does not encourage users to test release candidates at all, if found bugs don't get fixed. Maybe the next RCs can have a greater timeframe, so regressions found can get fixed before a release is made GA? Otherwise I don't see a point in testing RCs anymore. I did test it as soon as possible after it was announced in order to sort out possible regression bugs _before_ 3.4.1 gets released, as I'd like to use 3.4.1 in production. Can someone please enlighten me, what the release process is? I really thought regressions get fixed before a release. I'd also be happy if someone can tell me, that it's no regression but a fault on my side, so I can fix that. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

Il 05/05/2014 09:28, Sven Kieske ha scritto:
Am 02.05.2014 17:05, schrieb Sven Kieske:
May I ask what the point of RC testing is, when discovered regressions get retargeted for the next release?
I thought the policy was to not release something with a known regression?
Yes, and due to that policy the bug has been re-targeted back to 3.4.1 and re-added to the 3.4.1 blocker list. http://www.ovirt.org/OVirt_3.4_release-management#MUST MUST: No regressions from 3.3 Release
This does not encourage users to test release candidates at all, if found bugs don't get fixed.
Found bugs will be surely addressed according to above release criteria. If the bug is identified as blocker (and regressions are blockers) it must be fixed before GA.
Maybe the next RCs can have a greater timeframe, so regressions found can get fixed before a release is made GA?
If blockers (including regressions) are found, GA will be postponed until they will be fixed.
Otherwise I don't see a point in testing RCs anymore.
I did test it as soon as possible after it was announced in order to sort out possible regression bugs _before_ 3.4.1 gets released, as I'd like to use 3.4.1 in production.
And I really thank you for your testing!
Can someone please enlighten me, what the release process is?
I really thought regressions get fixed before a release.
I'd also be happy if someone can tell me, that it's no regression but a fault on my side, so I can fix that.
I can't judge about if the above bug is a real regression or not, added a comment in the BZ. I hope to have answered your questions. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

As always, thanks for the fast response. And thanks for re-adding as a blocker and the clarification. I still hope the bug is on my side, so 3.4.1 has not to be delayed much longer. It would be cool if some REST gurus could review my json code, and tell me if it is correct, or not. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

On 05/02/2014 05:05 PM, Sven Kieske wrote:
Hi,
please review this bug report:
I can't boot this vm via cloud init, this worked before, it causes an unhandled exception in jboss: https://bugzilla.redhat.com/show_bug.cgi?id=1093755
I'm aware I may have an error in my json syntax as this got changed from 3.3.x to 3.4.x . I tried to keep up with the changes and hope I got everything right.
So please correct my json, or if it is correct please help me debug while this raises an exception.
I believe I'm one of not too many people (maybe the only one?) who tests cloud-init via REST/json so maybe I hit a bug.
Thanks for your help in advance.
PS: Here again the json for lazy people who don't want to click links ;)
{"vm":{"initialization":{"cloud_init":{"host":{"address":"test"},"network_configuration":{"nics":{"nics":[{"name":"eth0","boot_protocol":"STATIC","network":{"ip":{"address":"10.211.0.236","netmask":"255.255.255.248","gateway":"10.211.0.233"}},"on_boot":true}]},"dns":{"servers":{"hosts":[{"address":"46.30.62.99"},{"address":"46.30.62.98"},{"address":"46.30.62.97"}]}}},"users":{"users":[{"name":"root","password":"#9Dh2--3xz-h95Zy"}]},"files":{"files":[{"name":"\/foo\/test","content":"test","type":"PLAINTEXT"}]}}}}}
There are two issues here. One is that the JSON isn't correct, the other is a bug when reporting the error. The correct JSON should look like this: { "name": "yourvm", "cluster": { "id": "49548b92-4eeb-448a-842d-3c323370e0b2" }, "template": { "id": "00000000-0000-0000-0000-000000000000" }, "initialization": { "cloud_init": { "host": { "address": "test" }, "network_configuration": { "nics": { "nic": [ { "name": "eth0", "boot_protocol": "STATIC", "network": { "ip": { "address": "10.211.0.236", "netmask": "255.255.255.248", "gateway": "10.211.0.233" } }, "on_boot": true } ] }, "dns": { "servers": { "host": [ { "address": "46.30.62.99" }, { "address": "46.30.62.98" }, { "address": "46.30.62.97" } ] } } }, "users": { "user": [ { "name": "root", "password": "#9Dh2--3xz-h95Zy" } ] }, "files": { "file": [ { "name": "\/foo\/test", "content": "test", "type": "PLAINTEXT" } ] } } } } There are some additional explanations in the bug. If you change your client to send the correct JSON then the VM should work correctly, as the bug only triggers when you send incorrect JSON. -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.

Thanks for the quick fix and the clarifcation regarding json. I will test asap and report back. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

I can confirm that the following json works to run-once a vm via rest, notice there are some differences to the json submitted by juan. I don't use this to create and start the vm in one step, the vm is already created: {"vm":{"initialization":{"cloud_init":{"host":{"address":"test"},"network_configuration":{"nics":{"nic":[{"name":"eth0","boot_protocol":"STATIC","network":{"ip":{"address":"10.211.0.244","netmask":"255.255.255.248","gateway":"10.211.0.241"}},"on_boot":true}]},"dns":{"servers":{"host":[{"address":"46.30.62.99"},{"address":"46.30.62.98"},{"address":"46.30.62.97"}]}}},"users":{"user":[{"name":"root","password":"#9Dh2--3xz-h95Zy"}]},"files":{"file":[{"name":"\/foo\/test","content":"test","type":"PLAINTEXT"}]}}}}} -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

On 05/06/2014 08:56 AM, Sven Kieske wrote:
I can confirm that the following json works to run-once a vm via rest, notice there are some differences to the json submitted by juan.
I don't use this to create and start the vm in one step, the vm is already created:
{"vm":{"initialization":{"cloud_init":{"host":{"address":"test"},"network_configuration":{"nics":{"nic":[{"name":"eth0","boot_protocol":"STATIC","network":{"ip":{"address":"10.211.0.244","netmask":"255.255.255.248","gateway":"10.211.0.241"}},"on_boot":true}]},"dns":{"servers":{"host":[{"address":"46.30.62.99"},{"address":"46.30.62.98"},{"address":"46.30.62.97"}]}}},"users":{"user":[{"name":"root","password":"#9Dh2--3xz-h95Zy"}]},"files":{"file":[{"name":"\/foo\/test","content":"test","type":"PLAINTEXT"}]}}}}}
Ok, I assumed that you were creating a VM, not starting it. The main difference between that JSON and the one I sent previously is the outer "vm" element. The reason for that is that starting a VM is different than creating it. Creating receives a VM entity as parameter, so it doesn't need the outer "vm" element. Starting doesn't receive a VM, but an Action entity, and the VM is just a member of that action. The outer "action" element isn't needed. Taking that into account your JSON is correct. I don't see other differences. Did I miss something? Anyhow, there is still a bug in the error reporting path. That needs to be fixed. -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.

Thanks for the answer and for fixing the error reporting path. Will there be a respin of the RC or will it just get included into 3.4.1 GA ? Am 06.05.2014 10:36, schrieb Juan Hernandez:
Ok, I assumed that you were creating a VM, not starting it.
The main difference between that JSON and the one I sent previously is the outer "vm" element. The reason for that is that starting a VM is different than creating it. Creating receives a VM entity as parameter, so it doesn't need the outer "vm" element. Starting doesn't receive a VM, but an Action entity, and the VM is just a member of that action. The outer "action" element isn't needed. Taking that into account your JSON is correct.
I don't see other differences. Did I miss something?
Anyhow, there is still a bug in the error reporting path. That needs to be fixed.
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

On 05/06/2014 11:22 AM, Sven Kieske wrote:
Thanks for the answer and for fixing the error reporting path. Will there be a respin of the RC or will it just get included into 3.4.1 GA ?
I'm trying to get it into 3.4.1 GA, and as the bug is currently a blocker 3.4.1 GA won't be released without it. I think that we aren't doing a respin of the RC.
Am 06.05.2014 10:36, schrieb Juan Hernandez:
Ok, I assumed that you were creating a VM, not starting it.
The main difference between that JSON and the one I sent previously is the outer "vm" element. The reason for that is that starting a VM is different than creating it. Creating receives a VM entity as parameter, so it doesn't need the outer "vm" element. Starting doesn't receive a VM, but an Action entity, and the VM is just a member of that action. The outer "action" element isn't needed. Taking that into account your JSON is correct.
I don't see other differences. Did I miss something?
Anyhow, there is still a bug in the error reporting path. That needs to be fixed.
-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.

Il 06/05/2014 11:34, Juan Hernandez ha scritto:
On 05/06/2014 11:22 AM, Sven Kieske wrote:
Thanks for the answer and for fixing the error reporting path. Will there be a respin of the RC or will it just get included into 3.4.1 GA ?
I'm trying to get it into 3.4.1 GA, and as the bug is currently a blocker 3.4.1 GA won't be released without it. I think that we aren't doing a respin of the RC.
We'll wait for it in order to release 3.4.1 GA, no RC respin planned.
Am 06.05.2014 10:36, schrieb Juan Hernandez:
Ok, I assumed that you were creating a VM, not starting it.
The main difference between that JSON and the one I sent previously is the outer "vm" element. The reason for that is that starting a VM is different than creating it. Creating receives a VM entity as parameter, so it doesn't need the outer "vm" element. Starting doesn't receive a VM, but an Action entity, and the VM is just a member of that action. The outer "action" element isn't needed. Taking that into account your JSON is correct.
I don't see other differences. Did I miss something?
Anyhow, there is still a bug in the error reporting path. That needs to be fixed.
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

On 6 May 2014, at 12:12, Sandro Bonazzola wrote:
Il 06/05/2014 11:34, Juan Hernandez ha scritto:
On 05/06/2014 11:22 AM, Sven Kieske wrote:
Thanks for the answer and for fixing the error reporting path. Will there be a respin of the RC or will it just get included into 3.4.1 GA ?
I'm trying to get it into 3.4.1 GA, and as the bug is currently a blocker 3.4.1 GA won't be released without it. I think that we aren't doing a respin of the RC.
We'll wait for it in order to release 3.4.1 GA, no RC respin planned.
Since it's "only" about a proper error message in case of invalid json, I don't think it should be a blocker…. If there is nothing else pending IMHO we should go ahead with the release, 3.4.2 is not that far away… Thanks, michal
Am 06.05.2014 10:36, schrieb Juan Hernandez:
Ok, I assumed that you were creating a VM, not starting it.
The main difference between that JSON and the one I sent previously is the outer "vm" element. The reason for that is that starting a VM is different than creating it. Creating receives a VM entity as parameter, so it doesn't need the outer "vm" element. Starting doesn't receive a VM, but an Action entity, and the VM is just a member of that action. The outer "action" element isn't needed. Taking that into account your JSON is correct.
I don't see other differences. Did I miss something?
Anyhow, there is still a bug in the error reporting path. That needs to be fixed.
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (4)
-
Juan Hernandez
-
Michal Skrivanek
-
Sandro Bonazzola
-
Sven Kieske