We are introducing Gluster functionality into ovirt-engine REST-API. Gluster entities are 'Volumes' and 'Bricks'. The question is: should they be called: 'volume'/'brick' or 'gluster_volume/gluster_brick'? (with or without the 'gluster' prefix)? There was a short conversation about this in a patch in Gerrit: http://gerrit.ovirt.org/#change,3918 Since there are conflicting opinions, I'm bringing it here for a resolution. Thanks, Ori. _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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

> On 05/06/2012 09:56 AM, Ori Liel wrote: >> We are introducing Gluster functionality into ovirt-engine >> REST-API. >> >> Gluster entities are 'Volumes' and 'Bricks'. The question is: >> should >> they be called: 'volume'/'brick' or 'gluster_volume/gluster_brick'? >> (with or without the 'gluster' prefix)? >> >> There was a short conversation about this in a patch in Gerrit: >> http://gerrit.ovirt.org/#change,3918 >> >> Since there are conflicting opinions, I'm bringing it here for a >> resolution. >> >> Thanks, >> >> Ori. >> >> _______________________________________________ >> 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 > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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)

> >> >> >>> On 05/06/2012 09:56 AM, Ori Liel wrote: >>>> We are introducing Gluster functionality into ovirt-engine >>>> REST-API. >>>> >>>> Gluster entities are 'Volumes' and 'Bricks'. The question is: >>>> should >>>> they be called: 'volume'/'brick' or >>>> 'gluster_volume/gluster_brick'? >>>> (with or without the 'gluster' prefix)? >>>> >>>> There was a short conversation about this in a patch in Gerrit: >>>> http://gerrit.ovirt.org/#change,3918 >>>> >>>> Since there are conflicting opinions, I'm bringing it here for a >>>> resolution. >>>> >>>> Thanks, >>>> >>>> Ori. >>>> >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel

On 05/07/2012 11:52 PM, Ayal Baron wrote: > > > ----- Original Message ----- >> 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) > > does it make sense to also have gluster/bricks ? if so, I would nest it, i.e. gluster/{volumes|bricks|...} bricks are host level, afair they are not used like this at all. gluster/xxx is interesting as well, though not parallel to current virt mappings (storage_domains, disks, etc., being root collections) shireesh - any thoughts about this approach: - do you want volumes as root collection, or only under cluster - if root, should these be glustervolumes like other root collection, or the under a gluster collection.

_______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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)

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

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.

_______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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

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