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?

----- Original Message ----- > From: "Juan Hernández" <jhernand(a)redhat.com&gt; > To: "Shmuel Melamud" <smelamud(a)redhat.com&gt;, devel(a)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