Re: [Engine-devel] restapi: 'gluster' prefix

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

> >> >> 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 > >