cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Min Chen <min.c...@citrix.com>
Subject Re: [PROPOSAL] List VM API enhancement
Date Fri, 07 Feb 2014 22:24:34 GMT
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" <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