cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <Alena.Prokharc...@citrix.com>
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.

-Alena.

On 2/7/14, 11:03 AM, "Koushik Das" <koushik.das@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 <min.chen@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" <koushik.das@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.hoogland@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
>>>> <Abhinandan.Prateek@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" <koushik.das@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
>>> 
>> 
>


Mime
View raw message