Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
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
_
Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
- 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 > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
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. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
On 06/10/2012 06:35 PM, Omer Frenkel wrote: > > > - Original Message - >> From: "Michael Pasternak" >> To: "Ori Liel" >> Cc: "Omer Frenkel" , "engine-devel" >> >> 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" To: "Omer Frenkel" Cc: "engine-devel" 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" >> To: "engine-devel" >> 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 true disks > > this is available. > >> 2. distinguish between true|false and >> true|false >>disks >> 3. maybe even worth taking >> false&&false >>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 true), 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
Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
- Original Message - > From: "Michael Pasternak" > To: "Ori Liel" > Cc: "Omer Frenkel" , "engine-devel" > > 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" > >> To: "Omer Frenkel" > >> Cc: "engine-devel" > >> 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" > To: "engine-devel" > 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 true disks > >>> > >>> this is available. > >>> > 2. distinguish between true|false and > true|false > disks > 3. maybe even worth taking > false&&false > 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 > >> true), > >> 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 > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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" >> To: "Omer Frenkel" >> Cc: "engine-devel" >> 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" To: "engine-devel" 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 true disks >>> >>> this is available. >>> 2. distinguish between true|false and true|false disks 3. maybe even worth taking false&&false 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 >> true), >> 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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
- Original Message - > From: "Michael Pasternak" > To: "Omer Frenkel" > Cc: "engine-devel" > 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" > >> To: "engine-devel" > >> 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 true disks > > > > this is available. > > > >> 2. distinguish between true|false and > >> true|false > >>disks > >> 3. maybe even worth taking > >> false&&false > >>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 > true), > 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 > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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" >> To: "engine-devel" >> 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 true disks > > this is available. > >> 2. distinguish between true|false and >> true|false >>disks >> 3. maybe even worth taking >> false&&false >>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 true), 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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
- Original Message - > From: "Michael Pasternak" > To: "engine-devel" > 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 true disks this is available. > 2. distinguish between true|false and > true|false >disks > 3. maybe even worth taking > false&&false >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 > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[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 true disks 2. distinguish between true|false and true|false disks 3. maybe even worth taking false&&false 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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Do we need genericApi project?
At least meanwhile, can I disable loading of GenericApiService bean during start up of jboss? - Original Message - From: "Itamar Heim" To: "Daniel Erez" Cc: "engine-devel" , "Michael Kublin" Sent: Sunday, June 10, 2012 12:44:08 PM Subject: Re: [Engine-devel] Do we need genericApi project? On 06/10/2012 12:33 PM, Daniel Erez wrote: > We may want to wait for the removal of the deprecated uicommon project (which > is in use by the old UserPortal). > uicommonweb doesn't use UiQueries any more (it's not depended on the > genericapi project) - so I think it can be removed. I'd wait to see it really isn't needed any more. it was added to cover a gap in which the UI is using logic which exists in methods in the business entities (IsLinux/IsWindows/Is64bit, etc.) which is something we wanted to decouple, and the UI queries expose these as queries for the UI rather than use the entities directly. so i'd say this still isn't fully utilized, rather than deprecated. > > > - Original Message - >> From: "Itamar Heim" >> To: "Michael Kublin" >> Cc: "engine-devel" >> Sent: Sunday, June 10, 2012 11:48:53 AM >> Subject: Re: [Engine-devel] Do we need genericApi project? >> >> On 06/10/2012 11:23 AM, Michael Kublin wrote: >>> Hi, >>> >>> I found that we have a ovirt-engine/frontend/api/genericapi >>> project, which is for my opinion is not at use any more. >>> If there are any reason that we want to keep it , maybe someone >>> using it and I missed these? >>> >>> Thanks Michael >>> ___ >>> Engine-devel mailing list >>> Engine-devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> iirc, it's intended to allow to add queries needed for the UI without >> adding them into the core. >> and looking at GetUserActionGroups, I see it is used for example by >> uicommon. >> >> (GWT still uses the generic api) >> ___ >> 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] Do we need genericApi project?
On 06/10/2012 12:33 PM, Daniel Erez wrote: We may want to wait for the removal of the deprecated uicommon project (which is in use by the old UserPortal). uicommonweb doesn't use UiQueries any more (it's not depended on the genericapi project) - so I think it can be removed. I'd wait to see it really isn't needed any more. it was added to cover a gap in which the UI is using logic which exists in methods in the business entities (IsLinux/IsWindows/Is64bit, etc.) which is something we wanted to decouple, and the UI queries expose these as queries for the UI rather than use the entities directly. so i'd say this still isn't fully utilized, rather than deprecated. - Original Message - From: "Itamar Heim" To: "Michael Kublin" Cc: "engine-devel" Sent: Sunday, June 10, 2012 11:48:53 AM Subject: Re: [Engine-devel] Do we need genericApi project? On 06/10/2012 11:23 AM, Michael Kublin wrote: Hi, I found that we have a ovirt-engine/frontend/api/genericapi project, which is for my opinion is not at use any more. If there are any reason that we want to keep it , maybe someone using it and I missed these? Thanks Michael ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel iirc, it's intended to allow to add queries needed for the UI without adding them into the core. and looking at GetUserActionGroups, I see it is used for example by uicommon. (GWT still uses the generic api) ___ 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] Do we need genericApi project?
We may want to wait for the removal of the deprecated uicommon project (which is in use by the old UserPortal). uicommonweb doesn't use UiQueries any more (it's not depended on the genericapi project) - so I think it can be removed. - Original Message - > From: "Itamar Heim" > To: "Michael Kublin" > Cc: "engine-devel" > Sent: Sunday, June 10, 2012 11:48:53 AM > Subject: Re: [Engine-devel] Do we need genericApi project? > > On 06/10/2012 11:23 AM, Michael Kublin wrote: > > Hi, > > > > I found that we have a ovirt-engine/frontend/api/genericapi > > project, which is for my opinion is not at use any more. > > If there are any reason that we want to keep it , maybe someone > > using it and I missed these? > > > > Thanks Michael > > ___ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > iirc, it's intended to allow to add queries needed for the UI without > adding them into the core. > and looking at GetUserActionGroups, I see it is used for example by > uicommon. > > (GWT still uses the generic api) > ___ > 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] Do we need genericApi project?
we don't use GetUserActionGroups (it's an unreachable code - can be deleted), IMHO we can remove the project. Thanks, Gilad. - Original Message - > From: "Itamar Heim" > To: "Michael Kublin" > Cc: "engine-devel" > Sent: Sunday, June 10, 2012 11:48:53 AM > Subject: Re: [Engine-devel] Do we need genericApi project? > > On 06/10/2012 11:23 AM, Michael Kublin wrote: > > Hi, > > > > I found that we have a ovirt-engine/frontend/api/genericapi > > project, which is for my opinion is not at use any more. > > If there are any reason that we want to keep it , maybe someone > > using it and I missed these? > > > > Thanks Michael > > ___ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > iirc, it's intended to allow to add queries needed for the UI without > adding them into the core. > and looking at GetUserActionGroups, I see it is used for example by > uicommon. > > (GWT still uses the generic api) > ___ > 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] Do we need genericApi project?
On 06/10/2012 11:23 AM, Michael Kublin wrote: Hi, I found that we have a ovirt-engine/frontend/api/genericapi project, which is for my opinion is not at use any more. If there are any reason that we want to keep it , maybe someone using it and I missed these? Thanks Michael ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel iirc, it's intended to allow to add queries needed for the UI without adding them into the core. and looking at GetUserActionGroups, I see it is used for example by uicommon. (GWT still uses the generic api) ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Do we need genericApi project?
On 06/10/2012 11:23 AM, Michael Kublin wrote: > Hi, > > I found that we have a ovirt-engine/frontend/api/genericapi project, which is > for my opinion is not at use any more. > If there are any reason that we want to keep it , maybe someone using it and > I missed these? IIUC, this was served in order to create a SOAP web service to server our clients. I also don't see a reason why we should continue and use this - All GWT based code does not use this (it uses GenericApiGWTServiceImpl to communicate with engine, which injects the EJB bean of Backend). This class as an obselete field of genericAPIService, which is no longer being injected (so a fix should be done at GWT side as well). Yair > > Thanks Michael > ___ > 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] Do we need genericApi project?
Hi, I found that we have a ovirt-engine/frontend/api/genericapi project, which is for my opinion is not at use any more. If there are any reason that we want to keep it , maybe someone using it and I missed these? Thanks Michael ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
