VM Parameters in REST API for Vm Pools
Hi! I'm currently working on adding VM parameters to VmPool collection in REST API. This will make possible to configure VMs on per pool basics like in the UI. The proposal is here: http://www.ovirt.org/Features/Vm_Parameters_in_REST_API_for_Vm_Pools Do anybody have any comments/suggestions? -- Shmuel
On 03/11/2015 05:47 PM, Shmuel Melamud wrote:
Hi!
I'm currently working on adding VM parameters to VmPool collection in REST API. This will make possible to configure VMs on per pool basics like in the UI.
The proposal is here: http://www.ovirt.org/Features/Vm_Parameters_in_REST_API_for_Vm_Pools
Do anybody have any comments/suggestions?
In your proposal you suggest to reuse the "template" element that appears inside the "vmpool" element. That "template" element is currently used as a link to the template that the pool is based on. If you add attributes to it it will look like they are attributes of the template itself, but still the link will point to the original template. For example: GET /vmpools/mypool <vmpool ...> ... <template id="mytemplate" href="/templates/mytemplate"> <type>desktop</type> <-- This is the type of the pool, not of the template </template> </vmpool> GET /templates/mytemplate <template ...> <type>server</type> <-- This is the type of the template, not of the pool ... </template> This difference may be confusing, at least. Also, users tend to take a resource representation from one URI and pass it to another URL (specially if using the Python or Java SDKs), for example: template = api.templates.get(name="mytemplate") api.vmpools.add( VMPool( template=mytemplate ) ) This would result in unexpectedly overriding all the properties of the pool with those of the template, so later changes to the template itself won't be reflected in the pool. To avoid these two issues I'd suggest to not use the existing "template" element, but add to the "vmpool" element all the required attributes: POST /vmpools <vmpool> <type>desktop</type> <display>...</display> ... </vmpool> -- 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.
----- Original Message -----
From: "Juan Hernández" <jhernand@redhat.com> To: "Shmuel Melamud" <smelamud@redhat.com>, devel@ovirt.org Sent: Wednesday, March 11, 2015 7:14:19 PM Subject: Re: [ovirt-devel] VM Parameters in REST API for Vm Pools
On 03/11/2015 05:47 PM, Shmuel Melamud wrote:
Hi!
I'm currently working on adding VM parameters to VmPool collection in REST API. This will make possible to configure VMs on per pool basics like in the UI.
The proposal is here: http://www.ovirt.org/Features/Vm_Parameters_in_REST_API_for_Vm_Pools
Do anybody have any comments/suggestions?
In your proposal you suggest to reuse the "template" element that appears inside the "vmpool" element. That "template" element is currently used as a link to the template that the pool is based on. If you add attributes to it it will look like they are attributes of the template itself, but still the link will point to the original template. For example:
GET /vmpools/mypool <vmpool ...> ... <template id="mytemplate" href="/templates/mytemplate"> <type>desktop</type> <-- This is the type of the pool, not of the template </template> </vmpool>
GET /templates/mytemplate <template ...> <type>server</type> <-- This is the type of the template, not of the pool ... </template>
This difference may be confusing, at least.
Also, users tend to take a resource representation from one URI and pass it to another URL (specially if using the Python or Java SDKs), for example:
template = api.templates.get(name="mytemplate") api.vmpools.add( VMPool( template=mytemplate ) )
This would result in unexpectedly overriding all the properties of the pool with those of the template, so later changes to the template itself won't be reflected in the pool.
To avoid these two issues I'd suggest to not use the existing "template" element, but add to the "vmpool" element all the required attributes:
POST /vmpools <vmpool> <type>desktop</type> <display>...</display> ... </vmpool>
what about embedding <vm> inside the pool? then it will have also template inside, and also correlate to the real implementation of the pool in the backend
-- 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. _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On 03/12/2015 12:52 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Juan Hernández" <jhernand@redhat.com> To: "Shmuel Melamud" <smelamud@redhat.com>, devel@ovirt.org Sent: Wednesday, March 11, 2015 7:14:19 PM Subject: Re: [ovirt-devel] VM Parameters in REST API for Vm Pools
On 03/11/2015 05:47 PM, Shmuel Melamud wrote:
Hi!
I'm currently working on adding VM parameters to VmPool collection in REST API. This will make possible to configure VMs on per pool basics like in the UI.
The proposal is here: http://www.ovirt.org/Features/Vm_Parameters_in_REST_API_for_Vm_Pools
Do anybody have any comments/suggestions?
In your proposal you suggest to reuse the "template" element that appears inside the "vmpool" element. That "template" element is currently used as a link to the template that the pool is based on. If you add attributes to it it will look like they are attributes of the template itself, but still the link will point to the original template. For example:
GET /vmpools/mypool <vmpool ...> ... <template id="mytemplate" href="/templates/mytemplate"> <type>desktop</type> <-- This is the type of the pool, not of the template </template> </vmpool>
GET /templates/mytemplate <template ...> <type>server</type> <-- This is the type of the template, not of the pool ... </template>
This difference may be confusing, at least.
Also, users tend to take a resource representation from one URI and pass it to another URL (specially if using the Python or Java SDKs), for example:
template = api.templates.get(name="mytemplate") api.vmpools.add( VMPool( template=mytemplate ) )
This would result in unexpectedly overriding all the properties of the pool with those of the template, so later changes to the template itself won't be reflected in the pool.
To avoid these two issues I'd suggest to not use the existing "template" element, but add to the "vmpool" element all the required attributes:
POST /vmpools <vmpool> <type>desktop</type> <display>...</display> ... </vmpool>
what about embedding <vm> inside the pool? then it will have also template inside, and also correlate to the real implementation of the pool in the backend
That doesn't have any of the two adverse effects that I described, so looks good. -- 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.
Hi!
what about embedding <vm> inside the pool? then it will have also template inside, and also correlate to the real implementation of the pool in the backend
That doesn't have any of the two adverse effects that I described, so looks good.
OK, so I'm going forward with new <vm> element inside <vm_pool>. Thank you for comments. -- Shmuel
participants (3)
-
Juan Hernández -
Omer Frenkel -
Shmuel Melamud