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(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel