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
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
