4:34 p.m.
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
11:19 p.m.
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?
11:28 p.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Sven Kieske" <S.Kieske(a)mittwald.de>, users(a)ovirt.org, "Moti
Asayag" <masayag(a)redhat.com>, "Mike Kolesnik"
<mkolesni(a)redhat.com>, "Lior Vernia" <lvernia(a)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?
10:02 a.m.
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
12:52 a.m.
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).
5:08 p.m.
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.
11:21 a.m.
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
3961
days inactive
3978
days old
6 comments
4 participants
participants (4)
-
Itamar Heim -
Juan Hernandez -
Moti Asayag -
Sven Kieske