[Engine-devel] RESTAPI: what is the purpose for /api/disks collection
IIUC originally this collection was suppose to keep all disks that can be shared between different vms and/or available to be attached to certain vm. At the moment this collection contains all disks in system while engine does not provide any search capabilities for it, in my view it not really useful, till we add search capabilities for being able: 1. locate <shareable>true</shareable> disks 2. distinguish between <shareable>true|false</shareable> and <active>true|false</active> disks 3. maybe even worth taking <active>false</active>&&<shareable>false</shareable> out of this collection and place them under api/clusters/xxx/disks (or under DC). this way /api/disks will only have disks that can be shared. your thoughts? -- Michael Pasternak RedHat, ENG-Virtualization R&D
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 4:18:14 PM Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
IIUC originally this collection was suppose to keep all disks that can be shared between different vms and/or available to be attached to certain vm.
At the moment this collection contains all disks in system while engine does not provide any search capabilities for it,
I'm pretty sure there is search for disks, or i misunderstood you, but you can run search query to get disks by alias and so.
in my view it not really useful, till we add search capabilities for being able:
1. locate <shareable>true</shareable> disks
this is available.
2. distinguish between <shareable>true|false</shareable> and <active>true|false</active> disks 3. maybe even worth taking <active>false</active>&&<shareable>false</shareable> out of this collection and place them under api/clusters/xxx/disks (or under DC). this way /api/disks will only have disks that can be shared.
your thoughts?
active is not a property of a disk, but a vm-disk, as unattached floating disks has no meaning of active. so maybe its place is unders /api/vms/xxx/disks (IIRC its already there)
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 06/10/2012 05:11 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 4:18:14 PM Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
IIUC originally this collection was suppose to keep all disks that can be shared between different vms and/or available to be attached to certain vm.
At the moment this collection contains all disks in system while engine does not provide any search capabilities for it,
I'm pretty sure there is search for disks, or i misunderstood you, but you can run search query to get disks by alias and so.
it is implemented with VdcQueryType.GetAllDisks not search.
in my view it not really useful, till we add search capabilities for being able:
1. locate <shareable>true</shareable> disks
this is available.
2. distinguish between <shareable>true|false</shareable> and <active>true|false</active> disks 3. maybe even worth taking <active>false</active>&&<shareable>false</shareable> out of this collection and place them under api/clusters/xxx/disks (or under DC). this way /api/disks will only have disks that can be shared.
your thoughts?
active is not a property of a disk, but a vm-disk, as unattached floating disks has no meaning of active. so maybe its place is unders /api/vms/xxx/disks (IIRC its already there),
it there, but also in same time it's under /api/disks (while <active>true</active>), so my question is how can you know if 'floating disk' is available to be attach to different vm?
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ 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 -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Omer Frenkel" <ofrenkel@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 5:27:10 PM Subject: Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
On 06/10/2012 05:11 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 4:18:14 PM Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
IIUC originally this collection was suppose to keep all disks that can be shared between different vms and/or available to be attached to certain vm.
At the moment this collection contains all disks in system while engine does not provide any search capabilities for it,
I'm pretty sure there is search for disks, or i misunderstood you, but you can run search query to get disks by alias and so.
it is implemented with VdcQueryType.GetAllDisks not search.
you can also use VdcQueryType.Search with SearchType.Disk (as in any other object search)
in my view it not really useful, till we add search capabilities for being able:
1. locate <shareable>true</shareable> disks
this is available.
2. distinguish between <shareable>true|false</shareable> and <active>true|false</active> disks 3. maybe even worth taking <active>false</active>&&<shareable>false</shareable> out of this collection and place them under api/clusters/xxx/disks (or under DC). this way /api/disks will only have disks that can be shared.
your thoughts?
active is not a property of a disk, but a vm-disk, as unattached floating disks has no meaning of active. so maybe its place is unders /api/vms/xxx/disks (IIRC its already there),
it there, but also in same time it's under /api/disks (while <active>true</active>), so my question is how can you know if 'floating disk' is available to be attach to different vm?
if the disk is floating, for sure it is available to be attached.
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak RedHat, ENG-Virtualization R&D
On 06/10/2012 05:30 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Omer Frenkel" <ofrenkel@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 5:27:10 PM Subject: Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
On 06/10/2012 05:11 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 4:18:14 PM Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
IIUC originally this collection was suppose to keep all disks that can be shared between different vms and/or available to be attached to certain vm.
At the moment this collection contains all disks in system while engine does not provide any search capabilities for it,
I'm pretty sure there is search for disks, or i misunderstood you, but you can run search query to get disks by alias and so.
it is implemented with VdcQueryType.GetAllDisks not search.
you can also use VdcQueryType.Search with SearchType.Disk (as in any other object search)
Ori, is there any special reason for /disks collection been implemented via query rather than VdcQueryType.Search?
in my view it not really useful, till we add search capabilities for being able:
1. locate <shareable>true</shareable> disks
this is available.
2. distinguish between <shareable>true|false</shareable> and <active>true|false</active> disks 3. maybe even worth taking <active>false</active>&&<shareable>false</shareable> out of this collection and place them under api/clusters/xxx/disks (or under DC). this way /api/disks will only have disks that can be shared.
your thoughts?
active is not a property of a disk, but a vm-disk, as unattached floating disks has no meaning of active. so maybe its place is unders /api/vms/xxx/disks (IIRC its already there),
it there, but also in same time it's under /api/disks (while <active>true</active>), so my question is how can you know if 'floating disk' is available to be attach to different vm?
if the disk is floating, for sure it is available to be attached.
from the feature page [1] "Any virtual disk can be in a floating state - by unattaching the disk from the VM/s. ", or "Floating disk - a disk that is not attached to any VM." from [2], so if disk attached to vm - it's "not floating" right? if so why it appear in /disks?, i think root collection /disks should contain only items available for common usage. (can't see any point in showing private vm disks there (such as not-shareable && not-floating)) [1] http://www.ovirt.org/wiki/Features/FloatingDisk [2] http://www.ovirt.org/wiki/Features/DetailedFloatingDisk,
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak RedHat, ENG-Virtualization R&D
-- Michael Pasternak RedHat, ENG-Virtualization R&D
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Ori Liel" <oliel@redhat.com> Cc: "Omer Frenkel" <ofrenkel@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 6:30:53 PM Subject: Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
On 06/10/2012 05:30 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Omer Frenkel" <ofrenkel@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 5:27:10 PM Subject: Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
On 06/10/2012 05:11 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 4:18:14 PM Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
IIUC originally this collection was suppose to keep all disks that can be shared between different vms and/or available to be attached to certain vm.
At the moment this collection contains all disks in system while engine does not provide any search capabilities for it,
I'm pretty sure there is search for disks, or i misunderstood you, but you can run search query to get disks by alias and so.
it is implemented with VdcQueryType.GetAllDisks not search.
you can also use VdcQueryType.Search with SearchType.Disk (as in any other object search)
Ori, is there any special reason for /disks collection been implemented via query rather than VdcQueryType.Search?
in my view it not really useful, till we add search capabilities for being able:
1. locate <shareable>true</shareable> disks
this is available.
2. distinguish between <shareable>true|false</shareable> and <active>true|false</active> disks 3. maybe even worth taking <active>false</active>&&<shareable>false</shareable> out of this collection and place them under api/clusters/xxx/disks (or under DC). this way /api/disks will only have disks that can be shared.
your thoughts?
active is not a property of a disk, but a vm-disk, as unattached floating disks has no meaning of active. so maybe its place is unders /api/vms/xxx/disks (IIRC its already there),
it there, but also in same time it's under /api/disks (while <active>true</active>), so my question is how can you know if 'floating disk' is available to be attach to different vm?
if the disk is floating, for sure it is available to be attached.
from the feature page [1] "Any virtual disk can be in a floating state - by unattaching the disk from the VM/s. ", or "Floating disk - a disk that is not attached to any VM." from [2],
correct
so if disk attached to vm - it's "not floating" right?
right
if so why it appear in /disks?, i think root collection /disks should contain only items available for common usage. (can't see any point in showing private vm disks there (such as not-shareable && not-floating))
well i guess its a way of looking at it, personally i think that there is no reason blocking data from the user, let the user decide if he would like to see all disks, or filter it with a simple query. you mentioned common usage, private templates also return in /templates, no? no one can use them but one user. maybe im the storage guy, and my 'usage' in the disks tab is to see how people are handling disks and storage (probably not so good example but just trying to say don't hide info from the users, you don't know all the use cases)
[1] http://www.ovirt.org/wiki/Features/FloatingDisk [2] http://www.ovirt.org/wiki/Features/DetailedFloatingDisk,
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak RedHat, ENG-Virtualization R&D
--
Michael Pasternak RedHat, ENG-Virtualization R&D
On 06/10/2012 06:35 PM, Omer Frenkel wrote:
if so why it appear in /disks?, i think root collection /disks should contain only items available for common usage. (can't see any point in showing private vm disks there (such as not-shareable&& not-floating))
i don't think it makes sense a disk will go away to a user from /disks once it was attached, etc. why not show here all disks?
well i guess its a way of looking at it, personally i think that there is no reason blocking data from the user, let the user decide if he would like to see all disks, or filter it with a simple query.
you mentioned common usage, private templates also return in /templates, no? no one can use them but one user. maybe im the storage guy, and my 'usage' in the disks tab is to see how people are handling disks and storage (probably not so good example but just trying to say don't hide info from the users, you don't know all the use cases)
not sure this is the same: private template will not show to a user without relevant permissions via the user api. admin api shows all objects, hence the private template as well.
On 06/10/2012 06:52 PM, Itamar Heim wrote:
On 06/10/2012 06:35 PM, Omer Frenkel wrote:
if so why it appear in /disks?, i think root collection /disks should contain only items available for common usage. (can't see any point in showing private vm disks there (such as not-shareable&& not-floating))
i don't think it makes sense a disk will go away to a user from /disks once it was attached, etc.
it's exactly the behaviour i'd like to achieve (only disks available for common usage shown), if you attached it to vm X and want detach it, go to vm/xx/disks/yy and detach it there, (btw if we want support showing all disks in /disks, we should have link from the disk->vm it attached to.)
why not show here all disks?
the use-case is client-side filtering, in sdk i provide this capability where it's not supported by ovirt-search (such as property based filtering etc.), getting big chunk of not relevant data, is show-stopper for this feature. in my other email, i suggested adding search-parameter for being able requesting extended list, while the default should be reduced.
well i guess its a way of looking at it, personally i think that there is no reason blocking data from the user, let the user decide if he would like to see all disks, or filter it with a simple query.
you mentioned common usage, private templates also return in /templates, no? no one can use them but one user. maybe im the storage guy, and my 'usage' in the disks tab is to see how people are handling disks and storage (probably not so good example but just trying to say don't hide info from the users, you don't know all the use cases)
not sure this is the same: private template will not show to a user without relevant permissions via the user api. admin api shows all objects, hence the private template as well.
-- Michael Pasternak RedHat, ENG-Virtualization R&D
----- Original Message -----
On 06/10/2012 06:52 PM, Itamar Heim wrote:
On 06/10/2012 06:35 PM, Omer Frenkel wrote:
if so why it appear in /disks?, i think root collection /disks should contain only items available for common usage. (can't see any point in showing private vm disks there (such as not-shareable&& not-floating))
i don't think it makes sense a disk will go away to a user from /disks once it was attached, etc.
it's exactly the behaviour i'd like to achieve (only disks available for common usage shown), if you attached it to vm X and want detach it, go to vm/xx/disks/yy and detach it there,
(btw if we want support showing all disks in /disks, we should have link from the disk->vm it attached to.)
why not show here all disks?
the use-case is client-side filtering, in sdk i provide this capability where it's not supported by ovirt-search (such as property based filtering etc.), getting big chunk of not relevant data, is show-stopper for this feature.
I totally disagree here. First of all define 'not relevant data'. A shareable disk can be already attached to a VM so should it or should it not be shown here? (obviously it should). Now I want to mark a disk as shareable and attach to another VM so I need to go first to the VM where it happens to currently reside, change it then go to the general collection and attach to another VM? I have a read only disk with movies (or whatever other type of data) on it, I don't care which vm it is currently attached to, I want to move it to a different vm now, so you'd make it mandatory for me to know which VM it is now attached to? It is so simple to do a for list in client side script that would filter according to whatever parameter user wants and the use cases vary so widely I see no reason to filter whatsoever Even if I have thousands of disks it would be fast to iterate over, it might be more convenient if I can filter server side, but show-stopper?
in my other email, i suggested adding search-parameter for being able requesting extended list, while the default should be reduced.
why only according to attached? why not according to other parameters? (raw/qcow2/qcow2V3 disks, disks with actual size >= 1TB, etc)
well i guess its a way of looking at it, personally i think that there is no reason blocking data from the user, let the user decide if he would like to see all disks, or filter it with a simple query.
you mentioned common usage, private templates also return in /templates, no? no one can use them but one user. maybe im the storage guy, and my 'usage' in the disks tab is to see how people are handling disks and storage (probably not so good example but just trying to say don't hide info from the users, you don't know all the use cases)
not sure this is the same: private template will not show to a user without relevant permissions via the user api. admin api shows all objects, hence the private template as well.
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 06/10/2012 11:49 PM, Ayal Baron wrote:
----- Original Message -----
On 06/10/2012 06:52 PM, Itamar Heim wrote:
On 06/10/2012 06:35 PM, Omer Frenkel wrote:
if so why it appear in /disks?, i think root collection /disks should contain only items available for common usage. (can't see any point in showing private vm disks there (such as not-shareable&& not-floating))
i don't think it makes sense a disk will go away to a user from /disks once it was attached, etc.
it's exactly the behaviour i'd like to achieve (only disks available for common usage shown), if you attached it to vm X and want detach it, go to vm/xx/disks/yy and detach it there,
(btw if we want support showing all disks in /disks, we should have link from the disk->vm it attached to.)
why not show here all disks?
the use-case is client-side filtering, in sdk i provide this capability where it's not supported by ovirt-search (such as property based filtering etc.), getting big chunk of not relevant data, is show-stopper for this feature.
I totally disagree here. First of all define 'not relevant data'.
i did, - disks that are not available for common usage (not shareable/not floating)
A shareable disk can be already attached to a VM so should it or should it not be shown here? (obviously it should).
based on told above - yes.
Now I want to mark a disk as shareable and attach to another VM so I need to go first to the VM where it happens to currently reside, change it
yes (if you not requested full collection), otherwise how will you choose the disk? by name? - who told that this name unique in collection ?..., doing that on concrete vm is less 'error prone' (agree with me that sharing wrong disk won't be nice ...)
then go to the general collection and attach to another VM?
or just took this disk representation and POST it to this /another vm/ disks collection, attach action is modelled as POST {disk} /api/vms/xxx/disks (same is true for general disks collection)
I have a read only disk with movies (or whatever other type of data) on it, I don't care which vm it is currently attached to, I want to move it to a different vm now, so you'd make it mandatory for me to know which VM it is now attached to?
what do you mean by /mandatory/? i think you confusing, it's not parameter for the attach action ... engine should be able telling admin to what vms shareable disk currently attached, otherwise how admin can detach it? from where? (detach is action on /api/vms/xxx/disks/yyy)
It is so simple to do a for list in client side script that would filter according to whatever parameter user wants and the use cases vary so widely I see no reason to filter whatsoever Even if I have thousands of disks it would be fast to iterate over,
true, iterating over is very fast, but you forgetting few tying things: marshalling/unmarshalling + transfer, 1. marshal thousands disks from java to xml 2. trasfer thousands disks over the wire 3. unmarshal thousands disks from xml to python 4. engine returns results in portions of 300, so you have to do four calls to engine in order to do this. that's true that it's not exactly show-stopper, but it still not scalable.
it might be more convenient if I can filter server side, but show-stopper?
in my other email, i suggested adding search-parameter for being able requesting extended list, while the default should be reduced.
why only according to attached? why not according to other parameters? (raw/qcow2/qcow2V3 disks, disks with actual size >= 1TB, etc)
this should be handled by search engine, we talking here about disks that's are not usable from user perspective.
well i guess its a way of looking at it, personally i think that there is no reason blocking data from the user, let the user decide if he would like to see all disks, or filter it with a simple query.
you mentioned common usage, private templates also return in /templates, no? no one can use them but one user. maybe im the storage guy, and my 'usage' in the disks tab is to see how people are handling disks and storage (probably not so good example but just trying to say don't hide info from the users, you don't know all the use cases)
not sure this is the same: private template will not show to a user without relevant permissions via the user api. admin api shows all objects, hence the private template as well.
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- Michael Pasternak RedHat, ENG-Virtualization R&D
On 06/10/2012 06:35 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Ori Liel" <oliel@redhat.com> Cc: "Omer Frenkel" <ofrenkel@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 6:30:53 PM Subject: Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
On 06/10/2012 05:30 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Omer Frenkel" <ofrenkel@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 5:27:10 PM Subject: Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
On 06/10/2012 05:11 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 4:18:14 PM Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
IIUC originally this collection was suppose to keep all disks that can be shared between different vms and/or available to be attached to certain vm.
At the moment this collection contains all disks in system while engine does not provide any search capabilities for it,
I'm pretty sure there is search for disks, or i misunderstood you, but you can run search query to get disks by alias and so.
it is implemented with VdcQueryType.GetAllDisks not search.
you can also use VdcQueryType.Search with SearchType.Disk (as in any other object search)
Ori, is there any special reason for /disks collection been implemented via query rather than VdcQueryType.Search?
in my view it not really useful, till we add search capabilities for being able:
1. locate <shareable>true</shareable> disks
this is available.
2. distinguish between <shareable>true|false</shareable> and <active>true|false</active> disks 3. maybe even worth taking <active>false</active>&&<shareable>false</shareable> out of this collection and place them under api/clusters/xxx/disks (or under DC). this way /api/disks will only have disks that can be shared.
your thoughts?
active is not a property of a disk, but a vm-disk, as unattached floating disks has no meaning of active. so maybe its place is unders /api/vms/xxx/disks (IIRC its already there),
it there, but also in same time it's under /api/disks (while <active>true</active>), so my question is how can you know if 'floating disk' is available to be attach to different vm?
if the disk is floating, for sure it is available to be attached.
from the feature page [1] "Any virtual disk can be in a floating state - by unattaching the disk from the VM/s. ", or "Floating disk - a disk that is not attached to any VM." from [2],
correct
so if disk attached to vm - it's "not floating" right?
right
if so why it appear in /disks?, i think root collection /disks should contain only items available for common usage. (can't see any point in showing private vm disks there (such as not-shareable && not-floating))
well i guess its a way of looking at it,
right
personally i think that there is no reason blocking data from the user, let the user decide if he would like to see all disks, or filter it with a simple query.
you mentioned common usage, private templates also return in /templates, no? no one can use them but one user. maybe im the storage guy, and my 'usage' in the disks tab is to see how people are handling disks and storage (probably not so good example but just trying to say don't hide info from the users, you don't know all the use cases)
i guess this is not about hiding, but about saving "too much information" from the user, the main difference with /templates is amount of data, cause when you have N templates in system and N*K vms and N*K*Q disks, it's too much data, so if part of this data is not relevant, i'd like to be able not showing it, query-parameter maybe good way to filter out disks not available for common usage, this way we can emulate "extended" results (the default will be reduced and i will expose matrix-parameter for this collection to see all disks) p.s about /templates example, previously we had only admin-api, and admins should be able seeing everything), now when we will support user-api, no user will see private template unless he has permit on it.
[1] http://www.ovirt.org/wiki/Features/FloatingDisk [2] http://www.ovirt.org/wiki/Features/DetailedFloatingDisk,
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak RedHat, ENG-Virtualization R&D
--
Michael Pasternak RedHat, ENG-Virtualization R&D
-- Michael Pasternak RedHat, ENG-Virtualization R&D
On 06/10/2012 05:30 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Omer Frenkel" <ofrenkel@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 5:27:10 PM Subject: Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
On 06/10/2012 05:11 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Sent: Sunday, June 10, 2012 4:18:14 PM Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
IIUC originally this collection was suppose to keep all disks that can be shared between different vms and/or available to be attached to certain vm.
At the moment this collection contains all disks in system while engine does not provide any search capabilities for it,
I'm pretty sure there is search for disks, or i misunderstood you, but you can run search query to get disks by alias and so.
it is implemented with VdcQueryType.GetAllDisks not search.
you can also use VdcQueryType.Search with SearchType.Disk (as in any other object search)
Ori, is there any special reason for /disks collection been implemented via query rather than VdcQueryType.Search?
I believe I thought at the time that it's not supported. I'll open a code-change to use search.
in my view it not really useful, till we add search capabilities for being able:
1. locate <shareable>true</shareable> disks
this is available.
2. distinguish between <shareable>true|false</shareable> and <active>true|false</active> disks 3. maybe even worth taking <active>false</active>&&<shareable>false</shareable> out of this collection and place them under api/clusters/xxx/disks (or under DC). this way /api/disks will only have disks that can be shared.
your thoughts?
active is not a property of a disk, but a vm-disk, as unattached floating disks has no meaning of active. so maybe its place is unders /api/vms/xxx/disks (IIRC its already there),
it there, but also in same time it's under /api/disks (while <active>true</active>), so my question is how can you know if 'floating disk' is available to be attach to different vm?
if the disk is floating, for sure it is available to be attached.
from the feature page [1] "Any virtual disk can be in a floating state - by unattaching the disk from the VM/s. ", or "Floating disk - a disk that is not attached to any VM." from [2],
so if disk attached to vm - it's "not floating" right? if so why it appear in /disks?, i think root collection /disks should contain only items available for common usage. (can't see any point in showing private vm disks there (such as not-shareable && not-floating))
[1] http://www.ovirt.org/wiki/Features/FloatingDisk [2] http://www.ovirt.org/wiki/Features/DetailedFloatingDisk,
--
Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak RedHat, ENG-Virtualization R&D
--
Michael Pasternak RedHat, ENG-Virtualization R&D
participants (5)
-
Ayal Baron -
Itamar Heim -
Michael Pasternak -
Omer Frenkel -
Ori Liel