Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Chiradeep.Vittal@citrix.com
 designates 66.165.176.89 as permitted sender)
From: Chiradeep Vittal <Chiradeep.Vittal@citrix.com>
To: CloudStack DeveloperList <cloudstack-dev@incubator.apache.org>
Date: Wed, 30 Jan 2013 14:39:29 -0800
Subject: Re: [DISCUSS] DeployVirtualMachine userdata enhancements
Thread-Topic: [DISCUSS] DeployVirtualMachine userdata enhancements
Thread-Index: Ac3/Oqv3+pzxKcdYQBuns8SafgfavA==
Message-ID: <CD2EE073.42A5A%chiradeep.vittal@citrix.com>
In-Reply-To: 
 <CANLSSBWJWEZLXzB4j6UR83LOGCFJ=Xk09QTSoVUqwDiEc61Z-g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.13.0.110805
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

+1 to all 3 issues identified.
-1 to breaking API (using PUT/DELETE etc)
The underlying limitation for userdata is from the size of the database
column.

We should continue supporting GET semantics for deployVirtualMachine, in
which case the limit would continue to be 2K. We can support POST for ALL
APIs in which case the user data would be limited by the size of the
database column again.

I don't mind increasing the size to 32K even.


On 1/30/13 11:03 AM, "Rohit Yadav" <bhaisaab@apache.org> wrote:

>From wiki: "While CS does support the POST method also, we are not
>aware of any cloudstack clients using this."
>
>So, while GET and POST are both supported by the api servlet (because
>of the base class), POST won't work now as we funnel all requests to a
>single method that assumes GET and parses args based on ampersand
>separated url vars. It would need fixing, issue #0.
>
>Next, the way parsing is done it does not create multimap, so if
>multiple args are passed, it would take the last value which the http
>rfc mentions they should be collected as array for a key, i.e. a
>multimap, this is issue #1.
>
>Lastly, the fix would be largely on client, i.e. the UI and
>cloudmonkey for example to send POST for certain apis and GET. I'm not
>in favour of making a non-rest api server behave like a rest one, so
>atmost we should fix #0 and #1 and accept only GET and POST, GET for
>all read apis and POST for all the create, delete and update apis. I'm
>in favor of deprecated the current api server for say next 1-2 years
>and start working on a full REST-compliant JAX-RS powered api server,
>issue #3
>
>#0 - https://issues.apache.org/jira/browse/CLOUDSTACK-1091
>#1 - https://issues.apache.org/jira/browse/CLOUDSTACK-1092
>#2 - https://issues.apache.org/jira/browse/CLOUDSTACK-1093
>
>Assigned all of them to myself, feel to reassign.
>
>Regards.
>
>On Wed, Jan 30, 2013 at 10:48 AM, Chip Childers
><chip.childers@sungard.com> wrote:
>> On Wed, Jan 30, 2013 at 3:17 AM, Koushik Das <koushik.das@citrix.com>
>>wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Ram Ganesh [mailto:Ram.Ganesh@citrix.com]
>>>> Sent: Wednesday, January 30, 2013 1:06 PM
>>>> To: cloudstack-dev@incubator.apache.org
>>>> Subject: RE: [DISCUSS] DeployVirtualMachine userdata enhancements
>>>>
>>>> > -----Original Message-----
>>>> > From: rohityadav89@gmail.com [mailto:rohityadav89@gmail.com] On
>>>> Behalf
>>>> > Of Rohit Yadav
>>>> > Sent: 30 January 2013 10:30
>>>> > To: cloudstack-dev@incubator.apache.org
>>>> > Subject: Re: [DISCUSS] DeployVirtualMachine userdata enhancements
>>>> >
>>>> > On Tue, Jan 29, 2013 at 8:30 PM, Nitin Mehta
>>>><Nitin.Mehta@citrix.com>
>>>> > wrote:
>>>> > > Good point Rohit, but I suggest making only those API's POST which
>>>> > create
>>>> > > a resource (like deployVm here) and not all of them.
>>>> >
>>>> > > Ideally, we need to be using the right http methods for a true
>>>> > restful web
>>>> > > service.
>>>> >
>>>> > Nice suggestion, while we can use GET for all read/list apis and
>>>>POST
>>>> > for rest kind of apis would work; so we should use correct HTTP
>>>> > request type, for example for general crud apps:
>>>> >
>>>> > create apis: POST
>>>> > list/read apis: GET
>>>> > update apis: PUT or POST
>>>> > delete apis: DELETE or POST
>>>> >
>>>> Per HTTP specs for update api we could use PUT. For delete apis we
>>>>could
>>>> stick with DELETE. That is true REST.
>>>>
>>>
>>> CS has explicit APIs to update/delete entities. In case of PUT/DELETE
>>>there is no need to pass any api name as long as the entity can be
>>>uniquely identified.
>>>
>>>>
>>>>
>>>> > > Also about the length part, how then we allow user data to be of
>>>> > > size
>>>> > 2kb
>>>> > > currently ?
>>>> >
>>>> > It's was a known issue, while it would work with most modern age
>>>> > browsers this was paid less attention. As Mice suggests, should we
>>>> > increase length of tags?
>>>> >
>>>> > Regards.
>>>> >
>>>> > >
>>>> > > On 30/01/13 9:43 AM, "Rohit Yadav" <bhaisaab@apache.org> wrote:
>>>> > >
>>>> > >>+1 But if we are sending base64 encoded userdata as part of POST,
>>>>we
>>>> > >>can increase the limit even further.
>>>> > >>
>>>> > >>-1 If userdata will be sent as part of GET query, based on the rfc
>>>> > [1]
>>>> > >>and from the widely used ugliest web browser [2] the GET url
>>>>length
>>>> > >>should be <=3D 2000 (we're already exceeding that how we send
>>>>userdata
>>>> > >>request at present).
>>>> > >>
>>>> > >>Suggestion: Make POST as the default way of requesting apis from
>>>> > >>mgmt server.
>>>> > >>
>>>> > >>[1] http://www.faqs.org/rfcs/rfc2616.html
>>>> > >>[2] http://support.microsoft.com/kb/q208427
>>>> > >>
>>>> > >>Regards.
>>>> > >>
>>>> > >>On Tue, Jan 29, 2013 at 7:40 PM, Hari Kannan
>>>> > >><hari.kannan@citrix.com>
>>>> > >>wrote:
>>>> > >>> Hello All,
>>>> > >>>
>>>> > >>> I wish to propose increasing the size of userdata to be passed
>>>> > along
>>>> > >>>with DeployVirtualMachine API - I have added some info here
>>>> >
>>>> >>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/DeployVirtua
>>>> > >>>l
>>>> > Machi
>>>> > >>>ne+userdata+enhancements
>>>> > >>>  along with a JIRA ticket
>>>> > >>>https://issues.apache.org/jira/browse/CLOUDSTACK-1086
>>>> > >>>
>>>> > >>>
>>>> > >>> Please review and comment
>>>> > >>>
>>>> > >>> Hari Kannan
>>>> > >
>>>
>>
>> Does this proposal (and the technical discussion above) mean that we
>> want our next feature release to break backward compatibility with 4.0
>> (and soon 4.1)?  If so, can someone please start a specific discuss
>> thread about that (elevating the decision from being tied to a
>> specific feature)?