Re: [PROPOSAL] List VM API enhancement

2014-03-11 Thread Koushik Das
, Is it ok to move ahead with #1 for now? Later on when there is a version change required, this can be revisited. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, 10 February 2014 5:11 PM To: dev Subject: Re: [PROPOSAL] List VM API enhancement I don't

RE: [PROPOSAL] List VM API enhancement

2014-02-13 Thread Daan Hoogland
Subject: Re: [PROPOSAL] List VM API enhancement I don't like the id that id will be used for a list of ids. I would like to see the two both added to the api. They don't even need to bee mutually exclusive. the (human) semantics of id and ids is (in english) quite different and should

RE: [PROPOSAL] List VM API enhancement

2014-02-12 Thread Koushik Das
with #1 for now? Later on when there is a version change required, this can be revisited. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Monday, 10 February 2014 5:11 PM To: dev Subject: Re: [PROPOSAL] List VM API enhancement I don't like the id that id

Re: [PROPOSAL] List VM API enhancement

2014-02-10 Thread Daan Hoogland
I don't like the id that id will be used for a list of ids. I would like to see the two both added to the api. They don't even need to bee mutually exclusive. the (human) semantics of id and ids is (in english) quite different and should be honored. regards, Daan On Fri, Feb 7, 2014 at 11:24 PM,

Re: [PROPOSAL] List VM API enhancement

2014-02-07 Thread Min Chen
Hi Koushik, I agree with the idea of supporting multiple IDs. But I may not like the idea of introducing another different query parameter ids for this purpose. Why cannot we just change current id parameter to take a list of values? This way, user will not need to use two different

RE: [PROPOSAL] List VM API enhancement

2014-02-07 Thread Alex Huang
] List VM API enhancement Hi Koushik, I agree with the idea of supporting multiple IDs. But I may not like the idea of introducing another different query parameter ids for this purpose. Why cannot we just change current id parameter to take a list of values? This way, user will not need

RE: [PROPOSAL] List VM API enhancement

2014-02-07 Thread Prachi Damle
Yes, agree to this as well. Accordingly we need to handle the getEntityOwnerId() dependency. -Original Message- From: Alex Huang [mailto:alex.hu...@citrix.com] Sent: Friday, February 07, 2014 10:06 AM To: dev@cloudstack.apache.org Subject: RE: [PROPOSAL] List VM API enhancement +1 It's

Re: [PROPOSAL] List VM API enhancement

2014-02-07 Thread Koushik Das
Good point Min. I also thought about it but looking at some of the existing APIs thought of keeping both. For e.g. in deploy VM api there is a parameter called 'networkids' which can take an array of network IDs. Note that the naming convention of ending in 's'. Now by this logic we should

Re: [PROPOSAL] List VM API enhancement

2014-02-07 Thread Alena Prokharchyk
We can just agree from now on to use the ³id for handling multiple ids. And of course, we can never delete the ³ID² parameter just to satisfy the old convention, as this is the most used parameter :) I can see that several existing commands - archive/deleteAlerts are using ApiConstants.IDs

Re: [PROPOSAL] List VM API enhancement

2014-02-07 Thread Koushik Das
@cloudstack.apache.org Subject: RE: [PROPOSAL] List VM API enhancement +1 It's confusing to have id and ids all over the place. We should just say all ids can come in arrays by default. --Alex -Original Message- From: Min Chen [mailto:min.c...@citrix.comhttp://citrix.com] Sent: Friday, February 7

Re: [PROPOSAL] List VM API enhancement

2014-02-07 Thread Min Chen
Yes. -min Sent from my iPhone On Feb 7, 2014, at 11:10 AM, Alena Prokharchyk alena.prokharc...@citrix.com wrote: We can just agree from now on to use the ³id for handling multiple ids. And of course, we can never delete the ³ID² parameter just to satisfy the old convention, as this is

[PROPOSAL] List VM API enhancement

2014-02-06 Thread Koushik Das
Currently list VM can only be called using a single VM ID. So if there is a need to query a set of VMs using ID then either multiple list VM calls need to be made or all VMs needs to be fetched and then do a client side filtering. Both approaches are sub-optimal - the former results in multiple

Re: [PROPOSAL] List VM API enhancement

2014-02-06 Thread Abhinandan Prateek
+1, The listVM call is one of the most resource intensive call. Any step to optimise it are welcome. On 06/02/14 2:01 pm, Koushik Das koushik@citrix.com wrote: Currently list VM can only be called using a single VM ID. So if there is a need to query a set of VMs using ID then either multiple

Re: [PROPOSAL] List VM API enhancement

2014-02-06 Thread Daan Hoogland
looks nice, it will be backed by the current query for one id? or will you write a findByIds()? On Thu, Feb 6, 2014 at 9:35 AM, Abhinandan Prateek abhinandan.prat...@citrix.com wrote: +1, The listVM call is one of the most resource intensive call. Any step to optimise it are welcome. On

Re: [PROPOSAL] List VM API enhancement

2014-02-06 Thread Koushik Das
Yes it will be like a findByIds() and the one id case is just a special case for this. On 06-Feb-2014, at 4:24 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: looks nice, it will be backed by the current query for one id? or will you write a findByIds()? On Thu, Feb 6, 2014 at 9:35 AM,

Re: [PROPOSAL] List VM API enhancement

2014-02-06 Thread Daan Hoogland
your a champion On Thu, Feb 6, 2014 at 12:24 PM, Koushik Das koushik@citrix.com wrote: Yes it will be like a findByIds() and the one id case is just a special case for this. On 06-Feb-2014, at 4:24 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: looks nice, it will be backed by the