[ovirt-devel] VM Parameters in REST API for Vm Pools

[Juan Hernández]

On 03/12/2015 12:52 PM, Omer Frenkel wrote:
> 
> 
> ----- Original Message -----
>> From: "Juan Hernández" <jhernand at redhat.com>
>> To: "Shmuel Melamud" <smelamud at redhat.com>, devel at 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.