cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <>
Subject Re: [PROPOSAL] List VM API enhancement
Date Fri, 07 Feb 2014 19:09:52 GMT
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.


On 2/7/14, 11:03 AM, "Koushik Das" <> 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 <> wrote:
>> Hi Koushik,
>> 	I agree with the idea of supporting multiple IDs. But I may not like
>> 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" <> 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
>>>>> step
>>>>> 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
>>>>>> 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
>>>>>> need a small subset from a very large number of VMs.
>>>>>> The proposal is to have an additional parameter to specify a list
>>>>>> 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
>>>>>> edd
>>>>>> 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

View raw message