[Engine-devel] restapi: 'gluster' prefix
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.
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. 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- Michael Pasternak RedHat, ENG-Virtualization R&D
----- 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- 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|...}
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@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.
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.
According to Geert, a key question in deciding whether gluster-volumes should exist in root collection is: are volumes potentially moveable between clusters? The answer, according to Shireesh, is no, and therefore Geert believes that the volumes should be under cluster. (Geert or Shireesh - if I misquoted you, please correct me). Bricks logically compose volumes, and thus are modelled under volumes.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On Tuesday 08 May 2012 10:45 AM, Itamar Heim wrote:
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.
Though bricks reside inside a host, they are logically part of a gluster volume, and hence should be sub-resources of the volume. [/api/.../(gluster)volumes/{(gluster)volume:id}/bricks].
gluster/xxx is interesting as well, though not parallel to current virt mappings (storage_domains, disks, etc., being root collections)
Separate gluster namespace does sound interesting, however it may not be feasible because we want the gluster volumes to be a collection sub-resource of the existing "cluster" resource. It can work if all the existing resources relevant to gluster are made available under it, which includes clusters and hosts. e.g. /api/gluster/clusters/{cluster:id}/hosts/{host:id}/... /api/gluster/clusters/{cluster:id}/volumes/{volume:id}/... It'll be interesting to see what others think about this.
shireesh - any thoughts about this approach: - do you want volumes as root collection, or only under cluster
Root collection for gluster volumes could be useful, though not critically important right now. We can revisit this at a later point of time.
- if root, should these be glustervolumes like other root collection, or the under a gluster collection.
This depends on whether we decide to go with the gluster namespace or not.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Thanks, Shireesh
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.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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?,
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- Michael Pasternak RedHat, ENG-Virtualization R&D
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- Michael Pasternak RedHat, ENG-Virtualization R&D
On 05/09/2012 11:46 AM, Ori Liel wrote:
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
sub-collections is the different story, you can create two volumes inheriting from same base class and return them according to the context, but this is implementation detail. -- Michael Pasternak RedHat, ENG-Virtualization R&D
On 05/09/2012 11:58 AM, Michael Pasternak wrote:
On 05/09/2012 11:46 AM, Ori Liel wrote:
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
sub-collections is the different story, you can create two volumes inheriting from same base class and return them according to the context, but this is implementation detail.
yes, but the question is why would entirely different entities will share the same type just because they are called in the same name in different projects. so gluster volumes is path of less resistance than trying to figure out how all future things which call themselves volumes will look like. we can revisit later and refactor/deprecate carry some backward compatibility as relevant.
participants (5)
-
Ayal Baron -
Itamar Heim -
Michael Pasternak -
Ori Liel -
Shireesh Anjal