Re: [Engine-devel] restapi: 'gluster' prefix
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 RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
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@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
Re: [Engine-devel] restapi: 'gluster' prefix
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 RD
___
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
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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
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.
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 RD
___
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
Re: [Engine-devel] restapi: 'gluster' prefix
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 RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] restapi: 'gluster' prefix
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. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] restapi: 'gluster' prefix
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
Re: [Engine-devel] restapi: 'gluster' prefix
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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] restapi: 'gluster' prefix
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 RD
___
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
Re: [Engine-devel] restapi: 'gluster' prefix
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 RD
___
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
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] restapi: 'gluster' prefix
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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] restapi: 'gluster' prefix
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 RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] restapi: 'gluster' prefix
- 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 RD ___ 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
