cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Min Chen <>
Subject Re: [PROPOSAL] List VM API enhancement
Date Fri, 07 Feb 2014 17:55:33 GMT
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.


On 2/6/14 3:24 AM, "Koushik Das" <> 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 <>
> 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
>> <> wrote:
>>> +1, The listVM call is one of the most resource intensive call. Any
>>> to optimise it are welcome.
>>> On 06/02/14 2:01 pm, "Koushik Das" <> 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
>>>> need to be made or all VMs needs to be fetched and then do a client
>>>> 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
>>>> IDs for which the data needs to be fetched. Using this the required
>>>> can be queried in an efficient manner. With the new parameter the
>>>> would look like
>>>> ac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba0134
>>>> The new 'ids' parameter will be mutually exclusive with the existing
>>>> parameter.
>>>> Let me know if there are any concerns/comments.
>>>> Thanks,
>>>> Koushik
>> -- 
>> Daan

View raw message