You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Koushik Das <ko...@citrix.com> on 2014/02/06 09:31:38 UTC
[PROPOSAL] List VM API enhancement
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 queries to database and the latter will be an overkill if you need a small subset from a very large number of VMs.
The proposal is to have an additional parameter to specify a list of VM IDs for which the data needs to be fetched. Using this the required VMs can be queried in an efficient manner. With the new parameter the syntax would look like
http://localhost:8096/api?command=listVirtualMachines&listAll=true&ids=eddac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba0134
The new 'ids' parameter will be mutually exclusive with the existing 'id' parameter.
Let me know if there are any concerns/comments.
Thanks,
Koushik
Re: [PROPOSAL] List VM API enhancement
Posted by Koushik Das <ko...@citrix.com>.
I looked at BaseListCmd.java and see the following.
Prachi, Are you referring to this or anything else?
public long getEntityOwnerId() {
// no owner is needed for list command
return 0;
}
On 08-Feb-2014, at 12:02 AM, Prachi Damle <Pr...@citrix.com>> wrote:
Yes, agree to this as well.
Accordingly we need to handle the getEntityOwnerId() dependency.
-----Original Message-----
From: Alex Huang [mailto:Alex.Huang@citrix.com<http://citrix.com>]
Sent: Friday, February 07, 2014 10:06 AM
To: dev@cloudstack.apache.org<ma...@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.chen@citrix.com<http://citrix.com>]
Sent: Friday, February 7, 2014 9:56 AM
To: dev@cloudstack.apache.org<ma...@cloudstack.apache.org>
Subject: Re: [PROPOSAL] 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 to use two different parameters for
single or multiple cases. Maintaining two different parameters for
similar purpose is error-prone. If you look at Amazon EC2 api, you
will notice that they are also using the similar convention, id parameter can be one or more.
Thanks
-min
On 2/6/14 3:24 AM, "Koushik Das" <ko...@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 <da...@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, Abhinandan Prateek
<Ab...@citrix.com>> wrote:
+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" <ko...@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 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 queries to database
and the latter will be an overkill if you need a small subset
from a very large number of VMs.
The proposal is to have an additional parameter to specify a list
of VM IDs for which the data needs to be fetched. Using this the
required VMs can be queried in an efficient manner. With the new
parameter the syntax would look like
http://localhost:8096/api?command=listVirtualMachines&listAll=true
&i
ds=
edd
ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-
254979ba01
34
The new 'ids' parameter will be mutually exclusive with the
existing 'id'
parameter.
Let me know if there are any concerns/comments.
Thanks,
Koushik
--
Daan
RE: [PROPOSAL] List VM API enhancement
Posted by Prachi Damle <Pr...@citrix.com>.
Yes, agree to this as well.
Accordingly we need to handle the getEntityOwnerId() dependency.
-----Original Message-----
From: Alex Huang [mailto:Alex.Huang@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 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.chen@citrix.com]
> Sent: Friday, February 7, 2014 9:56 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] 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 to use two different parameters for
> single or multiple cases. Maintaining two different parameters for
> similar purpose is error-prone. If you look at Amazon EC2 api, you
> will notice that they are also using the similar convention, id parameter can be one or more.
>
> Thanks
> -min
>
> On 2/6/14 3:24 AM, "Koushik Das" <ko...@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 <da...@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, Abhinandan Prateek
> >> <Ab...@citrix.com> wrote:
> >>> +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" <ko...@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 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 queries to database
> >>>>and the latter will be an overkill if you need a small subset
> >>>>from a very large number of VMs.
> >>>>
> >>>> The proposal is to have an additional parameter to specify a list
> >>>>of VM IDs for which the data needs to be fetched. Using this the
> >>>>required VMs can be queried in an efficient manner. With the new
> >>>>parameter the syntax would look like
> >>>>
> >>>>http://localhost:8096/api?command=listVirtualMachines&listAll=true
> >>>>&i
> >>>>ds=
> >>>>edd
> >>>>
> >>>>ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-
> 254979ba01
> >>>>34
> >>>>
> >>>> The new 'ids' parameter will be mutually exclusive with the
> >>>>existing 'id'
> >>>> parameter.
> >>>>
> >>>> Let me know if there are any concerns/comments.
> >>>>
> >>>> Thanks,
> >>>> Koushik
> >>>
> >>
> >>
> >>
> >> --
> >> Daan
> >
RE: [PROPOSAL] List VM API enhancement
Posted by Alex Huang <Al...@citrix.com>.
+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.chen@citrix.com]
> Sent: Friday, February 7, 2014 9:56 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] 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 to use two different parameters for single or
> multiple cases. Maintaining two different parameters for similar purpose is
> error-prone. If you look at Amazon EC2 api, you will notice that they are also
> using the similar convention, id parameter can be one or more.
>
> Thanks
> -min
>
> On 2/6/14 3:24 AM, "Koushik Das" <ko...@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 <da...@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, Abhinandan Prateek
> >> <Ab...@citrix.com> wrote:
> >>> +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" <ko...@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
> >>>>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 queries to database and the latter
> >>>>will be an overkill if you need a small subset from a very large
> >>>>number of VMs.
> >>>>
> >>>> The proposal is to have an additional parameter to specify a list
> >>>>of VM IDs for which the data needs to be fetched. Using this the
> >>>>required VMs can be queried in an efficient manner. With the new
> >>>>parameter the syntax would look like
> >>>>
> >>>>http://localhost:8096/api?command=listVirtualMachines&listAll=true&i
> >>>>ds=
> >>>>edd
> >>>>
> >>>>ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-
> 254979ba01
> >>>>34
> >>>>
> >>>> The new 'ids' parameter will be mutually exclusive with the
> >>>>existing 'id'
> >>>> parameter.
> >>>>
> >>>> Let me know if there are any concerns/comments.
> >>>>
> >>>> Thanks,
> >>>> Koushik
> >>>
> >>
> >>
> >>
> >> --
> >> Daan
> >
Re: [PROPOSAL] List VM API enhancement
Posted by Daan Hoogland <da...@gmail.com>.
your a champion
On Thu, Feb 6, 2014 at 12:24 PM, Koushik Das <ko...@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 <da...@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, Abhinandan Prateek
>> <Ab...@citrix.com> wrote:
>>> +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" <ko...@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 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 queries to database and the latter will be an overkill if you
>>>> need a small subset from a very large number of VMs.
>>>>
>>>> The proposal is to have an additional parameter to specify a list of VM
>>>> IDs for which the data needs to be fetched. Using this the required VMs
>>>> can be queried in an efficient manner. With the new parameter the syntax
>>>> would look like
>>>> http://localhost:8096/api?command=listVirtualMachines&listAll=true&ids=edd
>>>> ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba0134
>>>>
>>>> The new 'ids' parameter will be mutually exclusive with the existing 'id'
>>>> parameter.
>>>>
>>>> Let me know if there are any concerns/comments.
>>>>
>>>> Thanks,
>>>> Koushik
>>>
>>
>>
>>
>> --
>> Daan
>
--
Daan
Re: [PROPOSAL] List VM API enhancement
Posted by Koushik Das <ko...@citrix.com>.
Created a review request https://reviews.apache.org/r/19022/.
Since this is a small change not creating a separate merge request mail.
-Koushik
On 13-Feb-2014, at 2:23 PM, Daan Hoogland <da...@gmail.com> wrote:
> Koushik,
>
> I am afraid I am not. Using English for identifiers there is a semantic
> differnce of using <word>+'s' or just <word>. it is the same difference as
> using String or Collection<String>. For the sake of quality assurance and
> maintainability I call upon you to add a parameter for the use with
> multiple instances. Nomenclature matters a lot. There are more of these
> little 'English' rules implied in using a programming language, like the
> use of adjectives. They matter in Westerns languages and unless we define a
> system wide set of different rules let's stick with English.
>
> kind regards,
>
> Daan Hoogland
>
>
> Op 13 feb. 2014 08:32 schreef "Koushik Das" <ko...@citrix.com>:
>
>> I see that there are 2 different opinions
>>
>> 1. Use 'id' for multiple ids as well. This is simple and compact and
>> nothing breaks.
>> 2. Have both 'id' and 'ids'. This can lead to confusion if 'id' is not
>> deprecated (breaking change and would require a version change).
>>
>> Daan,
>> 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.hoogland@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 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, Min Chen <mi...@citrix.com> wrote:
>>> Yes.
>>>
>>> -min
>>>
>>> Sent from my iPhone
>>>
>>>> On Feb 7, 2014, at 11:10 AM, "Alena Prokharchyk" <
>> Alena.Prokharchyk@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 the most used parameter :)
>>>>
>>>> I can see that several existing commands - archive/deleteAlerts are
>>>> using ApiConstants.IDs parameter. We can mark IDs as deprecated, so
>>>> its no longer used by new commands.
>>>>
>>>> -Alena.
>>>>
>>>>> On 2/7/14, 11:03 AM, "Koushik Das" <ko...@citrix.com> wrote:
>>>>>
>>>>> 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 name the
>>>>> parameter 'ids' and remove the existing parameter 'id' which will be
>>>>> a breaking change. In case the existing 'id' parameter is used for
>>>>> multiple IDs that breaks the parameter naming convention.
>>>>>
>>>>> I am all in favour of using the existing 'id' parameter if there is
>>>>> no issues with breaking the naming convention.
>>>>>
>>>>>
>>>>>> On 07-Feb-2014, at 11:25 PM, Min Chen <mi...@citrix.com> wrote:
>>>>>>
>>>>>> 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 parameters for single or multiple cases.
>>>>>> Maintaining two different parameters for similar purpose is
>>>>>> error-prone. If you look at Amazon EC2 api, you will notice that
>>>>>> they are also using the similar convention, id parameter can be one
>>>>>> or more.
>>>>>>
>>>>>> Thanks
>>>>>> -min
>>>>>>
>>>>>>> On 2/6/14 3:24 AM, "Koushik Das" <ko...@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
>>>>>>> <da...@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, Abhinandan Prateek
>>>>>>>> <Ab...@citrix.com> wrote:
>>>>>>>>> +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" <ko...@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 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 queries to
>>>>>>>>>> database and the latter will be an overkill if you need a small
>>>>>>>>>> subset from a very large number of VMs.
>>>>>>>>>>
>>>>>>>>>> The proposal is to have an additional parameter to specify a
>>>>>>>>>> list of VM IDs for which the data needs to be fetched. Using
>>>>>>>>>> this the required VMs can be queried in an efficient manner.
>>>>>>>>>> With the new parameter the syntax would look like
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://localhost:8096/api?command=listVirtualMachines&listAll=t
>>>>>>>>>> rue&id
>>>>>>>>>> s=
>>>>>>>>>> edd
>>>>>>>>>>
>>>>>>>>>> ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-25497
>>>>>>>>>> 9ba013
>>>>>>>>>> 4
>>>>>>>>>>
>>>>>>>>>> The new 'ids' parameter will be mutually exclusive with the
>>>>>>>>>> existing 'id'
>>>>>>>>>> parameter.
>>>>>>>>>>
>>>>>>>>>> Let me know if there are any concerns/comments.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Koushik
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Daan
>>>>
>>
>>
>>
>> --
>> Daan
>>
RE: [PROPOSAL] List VM API enhancement
Posted by Daan Hoogland <da...@gmail.com>.
Koushik,
I am afraid I am not. Using English for identifiers there is a semantic
differnce of using <word>+'s' or just <word>. it is the same difference as
using String or Collection<String>. For the sake of quality assurance and
maintainability I call upon you to add a parameter for the use with
multiple instances. Nomenclature matters a lot. There are more of these
little 'English' rules implied in using a programming language, like the
use of adjectives. They matter in Westerns languages and unless we define a
system wide set of different rules let's stick with English.
kind regards,
Daan Hoogland
Op 13 feb. 2014 08:32 schreef "Koushik Das" <ko...@citrix.com>:
> I see that there are 2 different opinions
>
> 1. Use 'id' for multiple ids as well. This is simple and compact and
> nothing breaks.
> 2. Have both 'id' and 'ids'. This can lead to confusion if 'id' is not
> deprecated (breaking change and would require a version change).
>
> Daan,
> 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.hoogland@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 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, Min Chen <mi...@citrix.com> wrote:
> > Yes.
> >
> > -min
> >
> > Sent from my iPhone
> >
> >> On Feb 7, 2014, at 11:10 AM, "Alena Prokharchyk" <
> Alena.Prokharchyk@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 the most used parameter :)
> >>
> >> I can see that several existing commands - archive/deleteAlerts are
> >> using ApiConstants.IDs parameter. We can mark IDs as deprecated, so
> >> its no longer used by new commands.
> >>
> >> -Alena.
> >>
> >>> On 2/7/14, 11:03 AM, "Koushik Das" <ko...@citrix.com> wrote:
> >>>
> >>> 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 name the
> >>> parameter 'ids' and remove the existing parameter 'id' which will be
> >>> a breaking change. In case the existing 'id' parameter is used for
> >>> multiple IDs that breaks the parameter naming convention.
> >>>
> >>> I am all in favour of using the existing 'id' parameter if there is
> >>> no issues with breaking the naming convention.
> >>>
> >>>
> >>>> On 07-Feb-2014, at 11:25 PM, Min Chen <mi...@citrix.com> wrote:
> >>>>
> >>>> 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 parameters for single or multiple cases.
> >>>> Maintaining two different parameters for similar purpose is
> >>>> error-prone. If you look at Amazon EC2 api, you will notice that
> >>>> they are also using the similar convention, id parameter can be one
> >>>> or more.
> >>>>
> >>>> Thanks
> >>>> -min
> >>>>
> >>>>> On 2/6/14 3:24 AM, "Koushik Das" <ko...@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
> >>>>> <da...@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, Abhinandan Prateek
> >>>>>> <Ab...@citrix.com> wrote:
> >>>>>>> +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" <ko...@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 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 queries to
> >>>>>>>> database and the latter will be an overkill if you need a small
> >>>>>>>> subset from a very large number of VMs.
> >>>>>>>>
> >>>>>>>> The proposal is to have an additional parameter to specify a
> >>>>>>>> list of VM IDs for which the data needs to be fetched. Using
> >>>>>>>> this the required VMs can be queried in an efficient manner.
> >>>>>>>> With the new parameter the syntax would look like
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> http://localhost:8096/api?command=listVirtualMachines&listAll=t
> >>>>>>>> rue&id
> >>>>>>>> s=
> >>>>>>>> edd
> >>>>>>>>
> >>>>>>>> ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-25497
> >>>>>>>> 9ba013
> >>>>>>>> 4
> >>>>>>>>
> >>>>>>>> The new 'ids' parameter will be mutually exclusive with the
> >>>>>>>> existing 'id'
> >>>>>>>> parameter.
> >>>>>>>>
> >>>>>>>> Let me know if there are any concerns/comments.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Koushik
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Daan
> >>
>
>
>
> --
> Daan
>
RE: [PROPOSAL] List VM API enhancement
Posted by Koushik Das <ko...@citrix.com>.
I see that there are 2 different opinions
1. Use 'id' for multiple ids as well. This is simple and compact and nothing breaks.
2. Have both 'id' and 'ids'. This can lead to confusion if 'id' is not deprecated (breaking change and would require a version change).
Daan,
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.hoogland@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 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, Min Chen <mi...@citrix.com> wrote:
> Yes.
>
> -min
>
> Sent from my iPhone
>
>> On Feb 7, 2014, at 11:10 AM, "Alena Prokharchyk" <Al...@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 the most used parameter :)
>>
>> I can see that several existing commands - archive/deleteAlerts are
>> using ApiConstants.IDs parameter. We can mark IDs as deprecated, so
>> its no longer used by new commands.
>>
>> -Alena.
>>
>>> On 2/7/14, 11:03 AM, "Koushik Das" <ko...@citrix.com> wrote:
>>>
>>> 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 name the
>>> parameter 'ids' and remove the existing parameter 'id' which will be
>>> a breaking change. In case the existing 'id' parameter is used for
>>> multiple IDs that breaks the parameter naming convention.
>>>
>>> I am all in favour of using the existing 'id' parameter if there is
>>> no issues with breaking the naming convention.
>>>
>>>
>>>> On 07-Feb-2014, at 11:25 PM, Min Chen <mi...@citrix.com> wrote:
>>>>
>>>> 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 parameters for single or multiple cases.
>>>> Maintaining two different parameters for similar purpose is
>>>> error-prone. If you look at Amazon EC2 api, you will notice that
>>>> they are also using the similar convention, id parameter can be one
>>>> or more.
>>>>
>>>> Thanks
>>>> -min
>>>>
>>>>> On 2/6/14 3:24 AM, "Koushik Das" <ko...@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
>>>>> <da...@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, Abhinandan Prateek
>>>>>> <Ab...@citrix.com> wrote:
>>>>>>> +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" <ko...@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 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 queries to
>>>>>>>> database and the latter will be an overkill if you need a small
>>>>>>>> subset from a very large number of VMs.
>>>>>>>>
>>>>>>>> The proposal is to have an additional parameter to specify a
>>>>>>>> list of VM IDs for which the data needs to be fetched. Using
>>>>>>>> this the required VMs can be queried in an efficient manner.
>>>>>>>> With the new parameter the syntax would look like
>>>>>>>>
>>>>>>>>
>>>>>>>> http://localhost:8096/api?command=listVirtualMachines&listAll=t
>>>>>>>> rue&id
>>>>>>>> s=
>>>>>>>> edd
>>>>>>>>
>>>>>>>> ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-25497
>>>>>>>> 9ba013
>>>>>>>> 4
>>>>>>>>
>>>>>>>> The new 'ids' parameter will be mutually exclusive with the
>>>>>>>> existing 'id'
>>>>>>>> parameter.
>>>>>>>>
>>>>>>>> Let me know if there are any concerns/comments.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Koushik
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daan
>>
--
Daan
Re: [PROPOSAL] List VM API enhancement
Posted by Daan Hoogland <da...@gmail.com>.
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, Min Chen <mi...@citrix.com> wrote:
> Yes.
>
> -min
>
> Sent from my iPhone
>
>> On Feb 7, 2014, at 11:10 AM, "Alena Prokharchyk" <Al...@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 the most used parameter :)
>>
>> I can see that several existing commands - archive/deleteAlerts are using
>> ApiConstants.IDs parameter. We can mark IDs as deprecated, so its no
>> longer used by new commands.
>>
>> -Alena.
>>
>>> On 2/7/14, 11:03 AM, "Koushik Das" <ko...@citrix.com> wrote:
>>>
>>> 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 name the parameter 'ids' and
>>> remove the existing parameter 'id' which will be a breaking change. In
>>> case the existing 'id' parameter is used for multiple IDs that breaks the
>>> parameter naming convention.
>>>
>>> I am all in favour of using the existing 'id' parameter if there is no
>>> issues with breaking the naming convention.
>>>
>>>
>>>> On 07-Feb-2014, at 11:25 PM, Min Chen <mi...@citrix.com> wrote:
>>>>
>>>> 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 parameters
>>>> for single or multiple cases. Maintaining two different parameters for
>>>> similar purpose is error-prone. If you look at Amazon EC2 api, you will
>>>> notice that they are also using the similar convention, id parameter can
>>>> be one or more.
>>>>
>>>> Thanks
>>>> -min
>>>>
>>>>> On 2/6/14 3:24 AM, "Koushik Das" <ko...@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 <da...@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, Abhinandan Prateek
>>>>>> <Ab...@citrix.com> wrote:
>>>>>>> +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" <ko...@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 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 queries to database and the latter will be an overkill if
>>>>>>>> you
>>>>>>>> need a small subset from a very large number of VMs.
>>>>>>>>
>>>>>>>> The proposal is to have an additional parameter to specify a list of
>>>>>>>> VM
>>>>>>>> IDs for which the data needs to be fetched. Using this the required
>>>>>>>> VMs
>>>>>>>> can be queried in an efficient manner. With the new parameter the
>>>>>>>> syntax
>>>>>>>> would look like
>>>>>>>>
>>>>>>>>
>>>>>>>> http://localhost:8096/api?command=listVirtualMachines&listAll=true&id
>>>>>>>> s=
>>>>>>>> edd
>>>>>>>>
>>>>>>>> ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba013
>>>>>>>> 4
>>>>>>>>
>>>>>>>> The new 'ids' parameter will be mutually exclusive with the existing
>>>>>>>> 'id'
>>>>>>>> parameter.
>>>>>>>>
>>>>>>>> Let me know if there are any concerns/comments.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Koushik
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daan
>>
--
Daan
Re: [PROPOSAL] List VM API enhancement
Posted by Min Chen <mi...@citrix.com>.
Yes.
-min
Sent from my iPhone
> On Feb 7, 2014, at 11:10 AM, "Alena Prokharchyk" <Al...@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 the most used parameter :)
>
> I can see that several existing commands - archive/deleteAlerts are using
> ApiConstants.IDs parameter. We can mark IDs as deprecated, so its no
> longer used by new commands.
>
> -Alena.
>
>> On 2/7/14, 11:03 AM, "Koushik Das" <ko...@citrix.com> wrote:
>>
>> 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 name the parameter 'ids' and
>> remove the existing parameter 'id' which will be a breaking change. In
>> case the existing 'id' parameter is used for multiple IDs that breaks the
>> parameter naming convention.
>>
>> I am all in favour of using the existing 'id' parameter if there is no
>> issues with breaking the naming convention.
>>
>>
>>> On 07-Feb-2014, at 11:25 PM, Min Chen <mi...@citrix.com> wrote:
>>>
>>> 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 parameters
>>> for single or multiple cases. Maintaining two different parameters for
>>> similar purpose is error-prone. If you look at Amazon EC2 api, you will
>>> notice that they are also using the similar convention, id parameter can
>>> be one or more.
>>>
>>> Thanks
>>> -min
>>>
>>>> On 2/6/14 3:24 AM, "Koushik Das" <ko...@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 <da...@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, Abhinandan Prateek
>>>>> <Ab...@citrix.com> wrote:
>>>>>> +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" <ko...@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 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 queries to database and the latter will be an overkill if
>>>>>>> you
>>>>>>> need a small subset from a very large number of VMs.
>>>>>>>
>>>>>>> The proposal is to have an additional parameter to specify a list of
>>>>>>> VM
>>>>>>> IDs for which the data needs to be fetched. Using this the required
>>>>>>> VMs
>>>>>>> can be queried in an efficient manner. With the new parameter the
>>>>>>> syntax
>>>>>>> would look like
>>>>>>>
>>>>>>>
>>>>>>> http://localhost:8096/api?command=listVirtualMachines&listAll=true&id
>>>>>>> s=
>>>>>>> edd
>>>>>>>
>>>>>>> ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba013
>>>>>>> 4
>>>>>>>
>>>>>>> The new 'ids' parameter will be mutually exclusive with the existing
>>>>>>> 'id'
>>>>>>> parameter.
>>>>>>>
>>>>>>> Let me know if there are any concerns/comments.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Koushik
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Daan
>
Re: [PROPOSAL] List VM API enhancement
Posted by Alena Prokharchyk <Al...@citrix.com>.
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 parameter. We can mark IDs as deprecated, so its no
longer used by new commands.
-Alena.
On 2/7/14, 11:03 AM, "Koushik Das" <ko...@citrix.com> wrote:
>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 name the parameter 'ids' and
>remove the existing parameter 'id' which will be a breaking change. In
>case the existing 'id' parameter is used for multiple IDs that breaks the
>parameter naming convention.
>
>I am all in favour of using the existing 'id' parameter if there is no
>issues with breaking the naming convention.
>
>
>On 07-Feb-2014, at 11:25 PM, Min Chen <mi...@citrix.com> wrote:
>
>> 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 parameters
>> for single or multiple cases. Maintaining two different parameters for
>> similar purpose is error-prone. If you look at Amazon EC2 api, you will
>> notice that they are also using the similar convention, id parameter can
>> be one or more.
>>
>> Thanks
>> -min
>>
>> On 2/6/14 3:24 AM, "Koushik Das" <ko...@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 <da...@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, Abhinandan Prateek
>>>> <Ab...@citrix.com> wrote:
>>>>> +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" <ko...@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 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 queries to database and the latter will be an overkill if
>>>>>>you
>>>>>> need a small subset from a very large number of VMs.
>>>>>>
>>>>>> The proposal is to have an additional parameter to specify a list of
>>>>>> VM
>>>>>> IDs for which the data needs to be fetched. Using this the required
>>>>>> VMs
>>>>>> can be queried in an efficient manner. With the new parameter the
>>>>>> syntax
>>>>>> would look like
>>>>>>
>>>>>>
>>>>>>http://localhost:8096/api?command=listVirtualMachines&listAll=true&id
>>>>>>s=
>>>>>> edd
>>>>>>
>>>>>>ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba013
>>>>>>4
>>>>>>
>>>>>> The new 'ids' parameter will be mutually exclusive with the existing
>>>>>> 'id'
>>>>>> parameter.
>>>>>>
>>>>>> Let me know if there are any concerns/comments.
>>>>>>
>>>>>> Thanks,
>>>>>> Koushik
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Daan
>>>
>>
>
Re: [PROPOSAL] List VM API enhancement
Posted by Koushik Das <ko...@citrix.com>.
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 name the parameter 'ids' and remove the existing parameter 'id' which will be a breaking change. In case the existing 'id' parameter is used for multiple IDs that breaks the parameter naming convention.
I am all in favour of using the existing 'id' parameter if there is no issues with breaking the naming convention.
On 07-Feb-2014, at 11:25 PM, Min Chen <mi...@citrix.com> wrote:
> 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 parameters
> for single or multiple cases. Maintaining two different parameters for
> similar purpose is error-prone. If you look at Amazon EC2 api, you will
> notice that they are also using the similar convention, id parameter can
> be one or more.
>
> Thanks
> -min
>
> On 2/6/14 3:24 AM, "Koushik Das" <ko...@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 <da...@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, Abhinandan Prateek
>>> <Ab...@citrix.com> wrote:
>>>> +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" <ko...@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 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 queries to database and the latter will be an overkill if you
>>>>> need a small subset from a very large number of VMs.
>>>>>
>>>>> The proposal is to have an additional parameter to specify a list of
>>>>> VM
>>>>> IDs for which the data needs to be fetched. Using this the required
>>>>> VMs
>>>>> can be queried in an efficient manner. With the new parameter the
>>>>> syntax
>>>>> would look like
>>>>>
>>>>> http://localhost:8096/api?command=listVirtualMachines&listAll=true&ids=
>>>>> edd
>>>>> ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba0134
>>>>>
>>>>> The new 'ids' parameter will be mutually exclusive with the existing
>>>>> 'id'
>>>>> parameter.
>>>>>
>>>>> Let me know if there are any concerns/comments.
>>>>>
>>>>> Thanks,
>>>>> Koushik
>>>>
>>>
>>>
>>>
>>> --
>>> Daan
>>
>
Re: [PROPOSAL] List VM API enhancement
Posted by Min Chen <mi...@citrix.com>.
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 parameters
for single or multiple cases. Maintaining two different parameters for
similar purpose is error-prone. If you look at Amazon EC2 api, you will
notice that they are also using the similar convention, id parameter can
be one or more.
Thanks
-min
On 2/6/14 3:24 AM, "Koushik Das" <ko...@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 <da...@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, Abhinandan Prateek
>> <Ab...@citrix.com> wrote:
>>> +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" <ko...@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 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 queries to database and the latter will be an overkill if you
>>>> need a small subset from a very large number of VMs.
>>>>
>>>> The proposal is to have an additional parameter to specify a list of
>>>>VM
>>>> IDs for which the data needs to be fetched. Using this the required
>>>>VMs
>>>> can be queried in an efficient manner. With the new parameter the
>>>>syntax
>>>> would look like
>>>>
>>>>http://localhost:8096/api?command=listVirtualMachines&listAll=true&ids=
>>>>edd
>>>> ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba0134
>>>>
>>>> The new 'ids' parameter will be mutually exclusive with the existing
>>>>'id'
>>>> parameter.
>>>>
>>>> Let me know if there are any concerns/comments.
>>>>
>>>> Thanks,
>>>> Koushik
>>>
>>
>>
>>
>> --
>> Daan
>
Re: [PROPOSAL] List VM API enhancement
Posted by Koushik Das <ko...@citrix.com>.
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 <da...@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, Abhinandan Prateek
> <Ab...@citrix.com> wrote:
>> +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" <ko...@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 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 queries to database and the latter will be an overkill if you
>>> need a small subset from a very large number of VMs.
>>>
>>> The proposal is to have an additional parameter to specify a list of VM
>>> IDs for which the data needs to be fetched. Using this the required VMs
>>> can be queried in an efficient manner. With the new parameter the syntax
>>> would look like
>>> http://localhost:8096/api?command=listVirtualMachines&listAll=true&ids=edd
>>> ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba0134
>>>
>>> The new 'ids' parameter will be mutually exclusive with the existing 'id'
>>> parameter.
>>>
>>> Let me know if there are any concerns/comments.
>>>
>>> Thanks,
>>> Koushik
>>
>
>
>
> --
> Daan
Re: [PROPOSAL] List VM API enhancement
Posted by Daan Hoogland <da...@gmail.com>.
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
<Ab...@citrix.com> wrote:
> +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" <ko...@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 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 queries to database and the latter will be an overkill if you
>>need a small subset from a very large number of VMs.
>>
>>The proposal is to have an additional parameter to specify a list of VM
>>IDs for which the data needs to be fetched. Using this the required VMs
>>can be queried in an efficient manner. With the new parameter the syntax
>>would look like
>>http://localhost:8096/api?command=listVirtualMachines&listAll=true&ids=edd
>>ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba0134
>>
>>The new 'ids' parameter will be mutually exclusive with the existing 'id'
>>parameter.
>>
>>Let me know if there are any concerns/comments.
>>
>>Thanks,
>>Koushik
>
--
Daan
Re: [PROPOSAL] List VM API enhancement
Posted by Abhinandan Prateek <Ab...@citrix.com>.
+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" <ko...@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 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 queries to database and the latter will be an overkill if you
>need a small subset from a very large number of VMs.
>
>The proposal is to have an additional parameter to specify a list of VM
>IDs for which the data needs to be fetched. Using this the required VMs
>can be queried in an efficient manner. With the new parameter the syntax
>would look like
>http://localhost:8096/api?command=listVirtualMachines&listAll=true&ids=edd
>ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba0134
>
>The new 'ids' parameter will be mutually exclusive with the existing 'id'
>parameter.
>
>Let me know if there are any concerns/comments.
>
>Thanks,
>Koushik