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

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.

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