[Engine-devel] restapi: 'gluster' prefix

[Ori Liel]

>On 05/08/2012 12:11 PM, Itamar Heim wrote:
>> On 05/07/2012 08:13 PM, Itamar Heim wrote:
>>> On 05/07/2012 07:06 PM, Shireesh Anjal wrote:
>>>> On Monday 07 May 2012 02:06 AM, Ayal Baron wrote:
>>>>>
>>>>> ----- Original Message -----
>>>>>> i can't see any justification for the 'gluster' prefix,
>>>>>> as this is only additional /service/ provided by the project,
>>>>>> and Gluster now is a part of the RHT.
>>>>> I believe there needs to be an indication which service this is about.
>>>>> If we will support provisioning other storage types which also have
>>>>> volumes then we'd want a way to differentiate.
>>>>> However, isn't there a way to simply add gluster as the name space?
>>>>> i.e. somthing like: /api/gluster/.../volumes ? (instead of 'cluster'
>>>>> as it is redundant imho)
>>>>
>>>> A gluster volume is a cluster level entity, and hence
>>>> "/api/.../clusters/{cluster:id}" seems like the right parent URI for the
>>>> gluster volumes collection resource.
>>>
>>> that's true for all other root entities as well:
>>> - VM is DC/cluster level
>>> - template is DC level
>>> - disk is storage domain level
>>> - network is DC level
>>> - hosts are cluster level (for now)
>>>
>>> yet all of them have their own root collections as well.
>>>
>>> I think glustervolumes seems safest/most reasonable for now (either at
>>> cluster level or root level as well)
>>
>> thinking about this some more, I'm for
>>
>> cluster/xxx/gluster_volumes.
>>
>> reasoning:
>> 1. use gluster_volumes for now
>> avoids potential conflicts with non-gluster volumes
>
>why not having type in volume?,

I think 'volume' entity is too complex for that. 
A different storage vendor may have a completely different 
concept of a volume; for example, his volume may not have 
a 'block' sub-collection, and may not have any 'options' 
associated with it, and instead have all sorts of other 
stuff. 


>
>>
>> 2. start under cluster entity or root collection
>> going with the argument of can the entity move (host and vm can move, but a gluster_volume cannot move between clusters), I'm for going with gluster_volumes under the
>> cluster entity, and not the root collection.
>
>+1
>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>-- 
>
>Michael Pasternak
>RedHat, ENG-Virtualization R&D
>_______________________________________________
>Engine-devel mailing list
>Engine-devel at ovirt.org
>http://lists.ovirt.org/mailman/listinfo/engine-devel