[Users] VM MAC-Ranges and setting custom MACs via API
Hi, I got some questions regarding the MAC-Range in the engine and how to utilize the set custom mac feature via API: We want to set a custom MAC per VM via REST-API (JSON) The RSDL tells me, that this should be possible in general. However, I have two questions: Must the specified custom MAC be within the range defined in engine? I suppose not, as this range should just be a pool to take MACs from when engine itself acquires one for a vm. Also some users in IRC could use imported vms with custom macs, but using REST might yield different results? Does this work via JSON in ovirt-engine 3.3.2 ? I just learned that the JSON implementation is not feature complete until 3.4. so I wonder if I can use JSON instead of XML to achieve this. I can not wait for the 3.4. release anyway. We had so far no problem with using JSON beside a nasty Cloud-Init (documentation)bug (BZ 1045484) and we don't want to rewrite all our code to generate XML instead of JSON if we can avoid it. -- 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 01/03/2014 04:34 PM, Sven Kieske wrote:
Hi,
I got some questions regarding the MAC-Range in the engine and how to utilize the set custom mac feature via API:
We want to set a custom MAC per VM via REST-API (JSON) The RSDL tells me, that this should be possible in general.
However, I have two questions:
Must the specified custom MAC be within the range defined in engine?
I suppose not, as this range should just be a pool to take MACs from when engine itself acquires one for a vm. Also some users in IRC could use imported vms with custom macs, but using REST might yield different results?
Does this work via JSON in ovirt-engine 3.3.2 ?
I just learned that the JSON implementation is not feature complete until 3.4. so I wonder if I can use JSON instead of XML to achieve this.
I can not wait for the 3.4. release anyway.
We had so far no problem with using JSON beside a nasty Cloud-Init (documentation)bug (BZ 1045484) and we don't want to rewrite all our code to generate XML instead of JSON if we can avoid it.
iiuc, with moving to support json, some property name changes will happen (juan can provide more details). as for the mac question - moti/mike/lior?
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Sven Kieske" <S.Kieske@mittwald.de>, users@ovirt.org, "Moti Asayag" <masayag@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com>, "Lior Vernia" <lvernia@redhat.com> Sent: Sunday, January 5, 2014 11:19:38 PM Subject: Re: [Users] VM MAC-Ranges and setting custom MACs via API
On 01/03/2014 04:34 PM, Sven Kieske wrote:
Hi,
I got some questions regarding the MAC-Range in the engine and how to utilize the set custom mac feature via API:
We want to set a custom MAC per VM via REST-API (JSON) The RSDL tells me, that this should be possible in general.
However, I have two questions:
Must the specified custom MAC be within the range defined in engine?
Your assumption is correct, you can provide either a mac address from the pool or other.
I suppose not, as this range should just be a pool to take MACs from when engine itself acquires one for a vm. Also some users in IRC could use imported vms with custom macs, but using REST might yield different results?
Does this work via JSON in ovirt-engine 3.3.2 ?
I just learned that the JSON implementation is not feature complete until 3.4. so I wonder if I can use JSON instead of XML to achieve this.
I can not wait for the 3.4. release anyway.
We had so far no problem with using JSON beside a nasty Cloud-Init (documentation)bug (BZ 1045484) and we don't want to rewrite all our code to generate XML instead of JSON if we can avoid it.
iiuc, with moving to support json, some property name changes will happen (juan can provide more details). as for the mac question - moti/mike/lior?
Hi, thanks for your answers so far, Omer provided me already with an example of the changed properties:
deleteProtected turns into delete_protected
is there a complete list somewhere? this would be helpful to maintain our code and to prevent errors when we upgrade to 3.4. somewhere in time. Do these changes just occur for json or also for other APIs? Am 05.01.2014 22:19, schrieb Itamar Heim:
some property name changes will happen (juan can provide more details).
-- 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 01/06/2014 10:02 AM, Sven Kieske wrote:
Hi,
thanks for your answers so far, Omer provided me already with an example of the changed properties:
deleteProtected turns into delete_protected
is there a complete list somewhere? this would be helpful to maintain our code and to prevent errors when we upgrade to 3.4. somewhere in time.
Do these changes just occur for json or also for other APIs?
my understanding this is only for json - part of making it supported and well behaved.
Am 05.01.2014 22:19, schrieb Itamar Heim:
some property name changes will happen (juan can provide more details).
On 01/17/2014 11:52 PM, Itamar Heim wrote:
On 01/06/2014 10:02 AM, Sven Kieske wrote:
Hi,
thanks for your answers so far, Omer provided me already with an example of the changed properties:
deleteProtected turns into delete_protected
is there a complete list somewhere? this would be helpful to maintain our code and to prevent errors when we upgrade to 3.4. somewhere in time.
Do these changes just occur for json or also for other APIs?
my understanding this is only for json - part of making it supported and well behaved.
We are making this change in order to use exactly the same names in the XML and JSON representations. The change only affects the JSON representation, and it basically means that the names used in JSON will use underscores to separate words instead of changes in case. For example, instead of "deleteProtected" you will get "delete_protected", instead of "keyboardLayout" you will get "keyboard_layout", so on. In general, if you want to know what will be the new name, you can look at the current XML representation, the names used in the JSON representation will be exactly the same.
Am 05.01.2014 22:19, schrieb Itamar Heim:
some property name changes will happen (juan can provide more details).
-- 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 your clarification. I forwarded this information to my devs. Am 18.01.2014 16:08, schrieb Juan Hernandez:
We are making this change in order to use exactly the same names in the XML and JSON representations. The change only affects the JSON representation, and it basically means that the names used in JSON will use underscores to separate words instead of changes in case. For example, instead of "deleteProtected" you will get "delete_protected", instead of "keyboardLayout" you will get "keyboard_layout", so on.
In general, if you want to know what will be the new name, you can look at the current XML representation, the names used in the JSON representation will be exactly the same.
-- 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
participants (4)
-
Itamar Heim -
Juan Hernandez -
Moti Asayag -
Sven Kieske