[Engine-devel] restapi: 'gluster' prefix

[Ori Liel]

>On 05/09/2012 11:35 AM, Itamar Heim wrote:
>> On 05/09/2012 11:40 AM, Michael Pasternak wrote:
>>> 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?,
>>
>> because the different volumes would be entirely different entities not resembling each other
>
>it's still works for our api, as non relevant properties does not shown in resource representation,
>we using this concept all over the api.
>

properties - yes, but I'm afraid the sub-collections might be different and we don't 
have support for that

>both gluster and non gluster resources still be volumes so it's also works from the REST P.o.V.
>
>i guess the question we should ask ourself if we really want to have collection peer technology
>rather than differentiating between technologies by type.
>
>>
>>>
>>>>
>>>> 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