You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Shiva Teja <sh...@gmail.com> on 2013/04/26 21:59:30 UTC

[GSoC] Introduction and Project Discussion

Hi all,

I am Shiva Teja, an undergrad student from IIT Mandi, India. I will be
participating in GSoC this year. I'd like to work on the new CloudStack UI
with bootstrap project[1]. I've been experimenting with API for the past
few days. After reading a couple of blog posts by Sebastien, his recent
hack on this[2] and a recent discussion[3] on the mailing list about making
CloudStack API RESTfull, here are the things I plan to do.

1. A more "human", RESTfull wrapper API on top of CloudStack API using
Flask python framework. Something like "GET /users" will directly
correspond to "listUsers" API command. "DELETE /user/<id>" will correspond
to the respective "deleteUser" API call.

2. A complete UI designed using Twitter Bootstrap and Backbone.js.
Obviously this will use the API that I'll be making.

(An app made using Bootstrap and Backbone.js:
http://coenraets.org/directory/ )

Any suggestions/comments ?

[1] https://issues.apache.org/jira/browse/CLOUDSTACK-1778
[2] https://github.com/runseb/cloudstack-flask
[3]
http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201304.mbox/%3C20130424083847.GA11354%40cloud-2.local%3E

Thanks,
Shiva Teja.

Re: [GSoC] Introduction and Project Discussion

Posted by Sebastien Goasguen <ru...@gmail.com>.
On Apr 29, 2013, at 1:15 AM, Rohit Yadav <bh...@apache.org> wrote:

> On Mon, Apr 29, 2013 at 1:53 AM, Shiva Teja <sh...@gmail.com> wrote:
> 
>> Hi Rohit,
>> 
>> I think you made my work a lot easier :) I can use code from cloudmonkey to
>> generate API cache and then build the code for the wrapper using it.
>> 
>> I might need some information on this. How would a RESTful CloudStack API
>> look like ?
> 
> 
> This is a hard issue because the challenge is not just to implement
> something, but something that will be maintainable. Your APIs are your
> interface or contract to the outside world so once you give away your spec
> to the outside world, you've the burden to keep backward compatibility and
> not mess up when you do any kind of refactoring.
> 
> Some general rules I see are; all entities are nouns, the verbs are not
> part of the url but how you call them; so list/read would be GET, create
> would be POST, update would be PUT, remove/del would be DELETE... that said
> you can create your own X- headers to mean something. People have written
> books, gave talk on how to write good RESTful APIs.
> 
> 
>> If I get these basic rules, I am guessing it shouldn't be tough
>> to generate the wrapper.
>> 
> 
> The implementation won't be tough, but getting it right would be. Right now
> I'm just splitting the apiname at the camelCase's hump in cloudmonkey, so
> camel becomes a command and Case becomes the entity.
> 
> 
>> 
>> Here's a very basic idea. I am using the same terminology used in
>> cloudmonkey. In "listUsers", users is subject and list is the verb.
>> In most of the cases the URL for an API command can be something like
>> "baseurl/subject/verb" with an appropriately chosen HTTP method based on
>> the verb. For some "verbs" like list, get, update, delete, add, it doesn't
>> make sense to have them in the URL and using the appropriate HTTP method
>> would mean the same. So I'll have to write the rules for each verb. These
>> rules might contain method to be used for the verb, should the verb be in
>> the URL or not...etc. And use these rules to generate the wrapper.
>> 
> 
> It's not straight forward, for example create/add/generate are few words in
> apis which would be GET Apis in restful terms. One way would be to manually
> sort/group the apis, other would be to annotate each api with an entity
> name, RESTful type {one of GET, POST, PUT etc.} and parent (For example,
> /zone/pod/cluster makes sense?).
> 
> 
>> I am trying to decide these rules, so that they don't deviate from the
>> point of being a RESTful API. Will get back with final implementation
>> details before I finish my application for GSoC.
>> 
> 
> Lastly, talk to Sebastien or someone who would is participating in GSoC as
> a mentor because it's important to identify who would mentor you if they
> would, best of luck.


Shiva, 

You get the idea. At this time you just need to write a proposal with a plan/design/timeline/deliverables.
You won't have the answer a the time of submitting the proposal. What you need to write is your understanding of the project, your ideas to tackle it, challenges that you see coming up etc. Keep asking questions and maybe Rohit will keep giving you ideas :)

Any discussions on how to automate this wrapper (like you are discussing with Rohit) is perfect. You can even include some prototype code, sequence diagram, uml diagram etc. I am more interested on seeing how you propose to go from nothing to something and what challenges you think you will face.

On the web side of the project, you need to explain what are some of the limitations of the current design (if any) and how frameworks like bootstrap/backbone or others can help solve those limitations.

PS: I have to remind everyone that acceptance is not yet guaranteed. The proposals will be reviewed and CloudStack will get a number of GSoC slots.  That number is not yet known.

-Sebastien

> 
> Cheers.
> I'm skipping applying to being a GSoC mentor this year, pissed off from
> GSoC admins this year. FOSS is just going to dogs; fck they did not include
> one project that has no real company to back its development and really
> needs help; VideoLAN/VLC.
> 
> 
> 
>> Regard,
>> Shiva Teja(irc: teja)
>> 
>> 
>> On Sat, Apr 27, 2013 at 10:14 PM, Rohit Yadav <bh...@apache.org> wrote:
>> 
>>> Hi Shiva,
>>> 
>>> On Sat, Apr 27, 2013 at 1:29 AM, Shiva Teja <sh...@gmail.com>
>> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> I am Shiva Teja, an undergrad student from IIT Mandi, India. I will be
>>>> participating in GSoC this year. I'd like to work on the new CloudStack
>>> UI
>>>> with bootstrap project[1]. I've been experimenting with API for the
>> past
>>>> few days. After reading a couple of blog posts by Sebastien, his recent
>>>> hack on this[2] and a recent discussion[3] on the mailing list about
>>> making
>>>> CloudStack API RESTfull, here are the things I plan to do.
>>>> 
>>> 
>>> Have you started working on your plan or just proposing? Hope you have a
>>> setup and tried CloudStack on DevCloud. For starters I suggest you to
>>> download, build and deploy CloudStack, play around APIs, cloudmonkey (a
>>> CLI) and the API Discovery service because both of your idea proposals
>> are
>>> around APIs.
>>> 
>>> 1. A more "human", RESTfull wrapper API on top of CloudStack API using
>>>> Flask python framework. Something like "GET /users" will directly
>>>> correspond to "listUsers" API command. "DELETE /user/<id>" will
>>> correspond
>>>> to the respective "deleteUser" API call.
>>>> 
>>> 
>>> It's tricky, first you should get a full list of entities. It's a lot of
>>> hard work if you do it manually but you can do smartly if you use Api
>>> Discovery. There are more than 300+ APIs in CloudStack, now groupped as
>> per
>>> entities (see a package like org.apache.cloudstack.api.<entitiy>.<api cmd
>>> class>).
>>> 
>>> So, first you need to classify the entities, get it checked (like write
>>> tests) and then define these operations. Few of us are inclined towards
>>> rewriting an API server that is RESTful and not query based. The
>> challenge
>>> there is to reuse present cmd classes, one way is to use reflections and
>>> another round of api annotations refactoring. Easiest way would be to
>> just
>>> fix/add/reuse Api Discovery, or write something use metaprogamming that
>>> auto generates your wrapper.
>>> 
>>> I'm floating these ideas so you can think about it and come up with a
>>> strategy that creates maintainable, extendable code which would require
>>> less time to implement it.
>>> 
>>> 2. A complete UI designed using Twitter Bootstrap and Backbone.js.
>>>> Obviously this will use the API that I'll be making.
>>>> 
>>> 
>>> +1 This is a fantastic idea, a better, faster, modular UI that is
>>> responsive is much appreciated and we will have an alternative to the
>>> default one.
>>> 
>>> Avoid sending direct emails to anyone and feel free to reach out to the
>> dev
>>> ML, email like a boss™.
>>> 
>>> Happy hacking!
>>> 
>>> Cheers.
>>> 
>>> (An app made using Bootstrap and Backbone.js:
>>>> http://coenraets.org/directory/ )
>>>> 
>>>> Any suggestions/comments ?
>>>> 
>>>> [1] https://issues.apache.org/jira/browse/CLOUDSTACK-1778
>>>> [2] https://github.com/runseb/cloudstack-flask
>>>> [3]
>>>> 
>>>> 
>>> 
>> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201304.mbox/%3C20130424083847.GA11354%40cloud-2.local%3E
>>>> 
>>>> Thanks,
>>>> Shiva Teja.
>>>> 
>>> 
>>

Re: [GSoC] Introduction and Project Discussion

Posted by Prasanna Santhanam <ts...@apache.org>.
On Mon, Apr 29, 2013 at 10:45:02AM +0530, Rohit Yadav wrote:
> > If I get these basic rules, I am guessing it shouldn't be tough
> > to generate the wrapper.
> >
> 
> The implementation won't be tough, but getting it right would be. Right now
> I'm just splitting the apiname at the camelCase's hump in cloudmonkey, so
> camel becomes a command and Case becomes the entity.
> 

FWIW, while breaking down the entity - verb relationships for Marvin's
refactoring I used additional transformers based on prepositions. Because not
all entities follow the camelCase relationship:

Something like this:
transform_api, addAccountToProject -> ('addAccount', 'Project')
transform_api, addIpToNic -> ('addIp', 'Nic')
transform_api, addNicToVirtualMachine -> ('addNic', 'VirtualMachine')
transform_api, assignToGlobalLoadBalancerRule -> ('assign', 'GlobalLoadBalancerRule')
transform_api, assignToLoadBalancerRule -> ('assign', 'LoadBalancerRule')
transform_api, changeServiceForRouter -> ('changeService', 'Router')
transform_api, changeServiceForSystemVm -> ('changeService', 'SystemVm')
transform_api, changeServiceForVirtualMachine -> ('changeService', 'VirtualMachine')
transform_api, deleteAccountFromProject -> ('deleteAccount', 'Project')
transform_api, findHostsForMigration -> ('findHosts', 'Migration')
transform_api, findStoragePoolsForMigration -> ('findStoragePools', 'Migration')
transform_api, markDefaultZoneForAccount -> ('markDefaultZone', 'Account')
transform_api, prepareHostForMaintenance -> ('prepareHost', 'Maintenance')
transform_api, removeFromGlobalLoadBalancerRule -> ('remove', 'GlobalLoadBalancerRule')
transform_api, removeFromLoadBalancerRule -> ('remove', 'LoadBalancerRule')
transform_api, removeIpFromNic -> ('removeIp', 'Nic')
transform_api, removeNicFromVirtualMachine -> ('removeNic', 'VirtualMachine')
transform_api, resetPasswordForVirtualMachine -> ('resetPassword', 'VirtualMachine')
transform_api, resetSSHKeyForVirtualMachine -> ('resetSSHKey', 'VirtualMachine')
transform_api, revertToSnapshot -> ('revert', 'Snapshot')
transform_api, updateDefaultNicForVirtualMachine -> ('updateDefaultNic', 'VirtualMachine')
transform_api, markDefaultZoneForAccount -> ('markDefaultZone', 'Account')
transform_api, assignToGlobalLoadBalancerRule -> ('assign', 'GlobalLoadBalancerRule')
transform_api, removeFromGlobalLoadBalancerRule -> ('remove', 'GlobalLoadBalancerRule')
transform_api, assignToLoadBalancerRule -> ('assign', 'LoadBalancerRule')
transform_api, removeFromLoadBalancerRule -> ('remove', 'LoadBalancerRule')
transform_api, prepareHostForMaintenance -> ('prepareHost', 'Maintenance')
transform_api, findHostsForMigration -> ('findHosts', 'Migration')
transform_api, findStoragePoolsForMigration -> ('findStoragePools', 'Migration')
transform_api, addIpToNic -> ('addIp', 'Nic')
transform_api, removeIpFromNic -> ('removeIp', 'Nic')
transform_api, addAccountToProject -> ('addAccount', 'Project')
transform_api, deleteAccountFromProject -> ('deleteAccount', 'Project')
transform_api, changeServiceForRouter -> ('changeService', 'Router')
transform_api, revertToSnapshot -> ('revert', 'Snapshot')
transform_api, changeServiceForSystemVm -> ('changeService', 'SystemVm')
transform_api, addNicToVirtualMachine -> ('addNic', 'VirtualMachine')
transform_api, changeServiceForVirtualMachine -> ('changeService', 'VirtualMachine')
transform_api, removeNicFromVirtualMachine -> ('removeNic', 'VirtualMachine')
transform_api, resetPasswordForVirtualMachine -> ('resetPassword', 'VirtualMachine')
transform_api, resetSSHKeyForVirtualMachine -> ('resetSSHKey', 'VirtualMachine')
transform_api, updateDefaultNicForVirtualMachine -> ('updateDefaultNic', 'VirtualMachine')

This is done by the cs_entity_generator module in the marvin_refactor branch.

Thanks,

-- 
Prasanna.,

------------------------
Powered by BigRock.com

RE: [GSoC] Introduction and Project Discussion

Posted by kd...@apache.org.
I'm all for a Flask wrapper for the CloudStack API. Would make custom UIs
super easy(Proud Flask user here).


>-----Original Message-----
>From: Shiva Teja [mailto:shivatejau@gmail.com]
>Sent: Sunday, April 28, 2013 11:24 PM
>To: dev@cloudstack.apache.org
>Subject: Re: [GSoC] Introduction and Project Discussion
>
>This probably needs of lot of discussion. For now, I'll stick to basics and
>concentrate more on the UI. Thanks for the help.
>
>Regards,
>Shiva Teja.
>
>
>On Mon, Apr 29, 2013 at 10:45 AM, Rohit Yadav <bh...@apache.org>
>wrote:
>
>> On Mon, Apr 29, 2013 at 1:53 AM, Shiva Teja <sh...@gmail.com>
>wrote:
>>
>> > Hi Rohit,
>> >
>> > I think you made my work a lot easier :) I can use code from
>> > cloudmonkey
>> to
>> > generate API cache and then build the code for the wrapper using it.
>> >
>> > I might need some information on this. How would a RESTful
>> > CloudStack API look like ?
>>
>>
>> This is a hard issue because the challenge is not just to implement
>> something, but something that will be maintainable. Your APIs are your
>> interface or contract to the outside world so once you give away your
>> spec to the outside world, you've the burden to keep backward
>> compatibility and not mess up when you do any kind of refactoring.
>>
>> Some general rules I see are; all entities are nouns, the verbs are
>> not part of the url but how you call them; so list/read would be GET,
>> create would be POST, update would be PUT, remove/del would be
>> DELETE... that said you can create your own X- headers to mean
>> something. People have written books, gave talk on how to write good
>RESTful APIs.
>>
>>
>> > If I get these basic rules, I am guessing it shouldn't be tough to
>> > generate the wrapper.
>> >
>>
>> The implementation won't be tough, but getting it right would be.
>> Right now I'm just splitting the apiname at the camelCase's hump in
>> cloudmonkey, so camel becomes a command and Case becomes the entity.
>>
>>
>> >
>> > Here's a very basic idea. I am using the same terminology used in
>> > cloudmonkey. In "listUsers", users is subject and list is the verb.
>> > In most of the cases the URL for an API command can be something
>> > like "baseurl/subject/verb" with an appropriately chosen HTTP method
>> > based on the verb. For some "verbs" like list, get, update, delete,
>> > add, it
>> doesn't
>> > make sense to have them in the URL and using the appropriate HTTP
>> > method would mean the same. So I'll have to write the rules for each
>> > verb. These rules might contain method to be used for the verb,
>> > should the verb be in the URL or not...etc. And use these rules to
generate
>the wrapper.
>> >
>>
>> It's not straight forward, for example create/add/generate are few
>> words in apis which would be GET Apis in restful terms. One way would
>> be to manually sort/group the apis, other would be to annotate each
>> api with an entity name, RESTful type {one of GET, POST, PUT etc.} and
>> parent (For example, /zone/pod/cluster makes sense?).
>>
>>
>> > I am trying to decide these rules, so that they don't deviate from
>> > the point of being a RESTful API. Will get back with final
>> > implementation details before I finish my application for GSoC.
>> >
>>
>> Lastly, talk to Sebastien or someone who would is participating in
>> GSoC as a mentor because it's important to identify who would mentor
>> you if they would, best of luck.
>>
>> Cheers.
>> I'm skipping applying to being a GSoC mentor this year, pissed off
>> from GSoC admins this year. FOSS is just going to dogs; fck they did
>> not include one project that has no real company to back its
>> development and really needs help; VideoLAN/VLC.
>>
>>
>>
>> > Regard,
>> > Shiva Teja(irc: teja)
>> >
>> >
>> > On Sat, Apr 27, 2013 at 10:14 PM, Rohit Yadav <bh...@apache.org>
>> wrote:
>> >
>> > > Hi Shiva,
>> > >
>> > > On Sat, Apr 27, 2013 at 1:29 AM, Shiva Teja <sh...@gmail.com>
>> > wrote:
>> > >
>> > > > Hi all,
>> > > >
>> > > > I am Shiva Teja, an undergrad student from IIT Mandi, India. I
>> > > > will
>> be
>> > > > participating in GSoC this year. I'd like to work on the new
>> CloudStack
>> > > UI
>> > > > with bootstrap project[1]. I've been experimenting with API for
>> > > > the
>> > past
>> > > > few days. After reading a couple of blog posts by Sebastien, his
>> recent
>> > > > hack on this[2] and a recent discussion[3] on the mailing list
>> > > > about
>> > > making
>> > > > CloudStack API RESTfull, here are the things I plan to do.
>> > > >
>> > >
>> > > Have you started working on your plan or just proposing? Hope you
>> > > have
>> a
>> > > setup and tried CloudStack on DevCloud. For starters I suggest you
>> > > to download, build and deploy CloudStack, play around APIs,
>> > > cloudmonkey (a
>> > > CLI) and the API Discovery service because both of your idea
>> > > proposals
>> > are
>> > > around APIs.
>> > >
>> > > 1. A more "human", RESTfull wrapper API on top of CloudStack API
>> > > using
>> > > > Flask python framework. Something like "GET /users" will
>> > > > directly correspond to "listUsers" API command. "DELETE
>> > > > /user/<id>" will
>> > > correspond
>> > > > to the respective "deleteUser" API call.
>> > > >
>> > >
>> > > It's tricky, first you should get a full list of entities. It's a
>> > > lot
>> of
>> > > hard work if you do it manually but you can do smartly if you use
>> > > Api Discovery. There are more than 300+ APIs in CloudStack, now
>> > > groupped as
>> > per
>> > > entities (see a package like
>> > > org.apache.cloudstack.api.<entitiy>.<api
>> cmd
>> > > class>).
>> > >
>> > > So, first you need to classify the entities, get it checked (like
>> > > write
>> > > tests) and then define these operations. Few of us are inclined
>> > > towards rewriting an API server that is RESTful and not query
>> > > based. The
>> > challenge
>> > > there is to reuse present cmd classes, one way is to use
>> > > reflections
>> and
>> > > another round of api annotations refactoring. Easiest way would be
>> > > to
>> > just
>> > > fix/add/reuse Api Discovery, or write something use metaprogamming
>> > > that auto generates your wrapper.
>> > >
>> > > I'm floating these ideas so you can think about it and come up
>> > > with a strategy that creates maintainable, extendable code which
>> > > would require less time to implement it.
>> > >
>> > > 2. A complete UI designed using Twitter Bootstrap and Backbone.js.
>> > > > Obviously this will use the API that I'll be making.
>> > > >
>> > >
>> > > +1 This is a fantastic idea, a better, faster, modular UI that is
>> > > responsive is much appreciated and we will have an alternative to
>> > > the default one.
>> > >
>> > > Avoid sending direct emails to anyone and feel free to reach out
>> > > to the
>> > dev
>> > > ML, email like a bossT.
>> > >
>> > > Happy hacking!
>> > >
>> > > Cheers.
>> > >
>> > > (An app made using Bootstrap and Backbone.js:
>> > > > http://coenraets.org/directory/ )
>> > > >
>> > > > Any suggestions/comments ?
>> > > >
>> > > > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-1778
>> > > > [2] https://github.com/runseb/cloudstack-flask
>> > > > [3]
>> > > >
>> > > >
>> > >
>> >
>> http://mail-archives.apache.org/mod_mbox/cloudstack-
>dev/201304.mbox/%3
>> C20130424083847.GA11354%40cloud-2.local%3E
>> > > >
>> > > > Thanks,
>> > > > Shiva Teja.
>> > > >
>> > >
>> >
>>

Re: [GSoC] Introduction and Project Discussion

Posted by Shiva Teja <sh...@gmail.com>.
This probably needs of lot of discussion. For now, I'll stick to basics and
concentrate more on the UI. Thanks for the help.

Regards,
Shiva Teja.


On Mon, Apr 29, 2013 at 10:45 AM, Rohit Yadav <bh...@apache.org> wrote:

> On Mon, Apr 29, 2013 at 1:53 AM, Shiva Teja <sh...@gmail.com> wrote:
>
> > Hi Rohit,
> >
> > I think you made my work a lot easier :) I can use code from cloudmonkey
> to
> > generate API cache and then build the code for the wrapper using it.
> >
> > I might need some information on this. How would a RESTful CloudStack API
> > look like ?
>
>
> This is a hard issue because the challenge is not just to implement
> something, but something that will be maintainable. Your APIs are your
> interface or contract to the outside world so once you give away your spec
> to the outside world, you've the burden to keep backward compatibility and
> not mess up when you do any kind of refactoring.
>
> Some general rules I see are; all entities are nouns, the verbs are not
> part of the url but how you call them; so list/read would be GET, create
> would be POST, update would be PUT, remove/del would be DELETE... that said
> you can create your own X- headers to mean something. People have written
> books, gave talk on how to write good RESTful APIs.
>
>
> > If I get these basic rules, I am guessing it shouldn't be tough
> > to generate the wrapper.
> >
>
> The implementation won't be tough, but getting it right would be. Right now
> I'm just splitting the apiname at the camelCase's hump in cloudmonkey, so
> camel becomes a command and Case becomes the entity.
>
>
> >
> > Here's a very basic idea. I am using the same terminology used in
> > cloudmonkey. In "listUsers", users is subject and list is the verb.
> > In most of the cases the URL for an API command can be something like
> > "baseurl/subject/verb" with an appropriately chosen HTTP method based on
> > the verb. For some "verbs" like list, get, update, delete, add, it
> doesn't
> > make sense to have them in the URL and using the appropriate HTTP method
> > would mean the same. So I'll have to write the rules for each verb. These
> > rules might contain method to be used for the verb, should the verb be in
> > the URL or not...etc. And use these rules to generate the wrapper.
> >
>
> It's not straight forward, for example create/add/generate are few words in
> apis which would be GET Apis in restful terms. One way would be to manually
> sort/group the apis, other would be to annotate each api with an entity
> name, RESTful type {one of GET, POST, PUT etc.} and parent (For example,
> /zone/pod/cluster makes sense?).
>
>
> > I am trying to decide these rules, so that they don't deviate from the
> > point of being a RESTful API. Will get back with final implementation
> > details before I finish my application for GSoC.
> >
>
> Lastly, talk to Sebastien or someone who would is participating in GSoC as
> a mentor because it's important to identify who would mentor you if they
> would, best of luck.
>
> Cheers.
> I'm skipping applying to being a GSoC mentor this year, pissed off from
> GSoC admins this year. FOSS is just going to dogs; fck they did not include
> one project that has no real company to back its development and really
> needs help; VideoLAN/VLC.
>
>
>
> > Regard,
> > Shiva Teja(irc: teja)
> >
> >
> > On Sat, Apr 27, 2013 at 10:14 PM, Rohit Yadav <bh...@apache.org>
> wrote:
> >
> > > Hi Shiva,
> > >
> > > On Sat, Apr 27, 2013 at 1:29 AM, Shiva Teja <sh...@gmail.com>
> > wrote:
> > >
> > > > Hi all,
> > > >
> > > > I am Shiva Teja, an undergrad student from IIT Mandi, India. I will
> be
> > > > participating in GSoC this year. I'd like to work on the new
> CloudStack
> > > UI
> > > > with bootstrap project[1]. I've been experimenting with API for the
> > past
> > > > few days. After reading a couple of blog posts by Sebastien, his
> recent
> > > > hack on this[2] and a recent discussion[3] on the mailing list about
> > > making
> > > > CloudStack API RESTfull, here are the things I plan to do.
> > > >
> > >
> > > Have you started working on your plan or just proposing? Hope you have
> a
> > > setup and tried CloudStack on DevCloud. For starters I suggest you to
> > > download, build and deploy CloudStack, play around APIs, cloudmonkey (a
> > > CLI) and the API Discovery service because both of your idea proposals
> > are
> > > around APIs.
> > >
> > > 1. A more "human", RESTfull wrapper API on top of CloudStack API using
> > > > Flask python framework. Something like "GET /users" will directly
> > > > correspond to "listUsers" API command. "DELETE /user/<id>" will
> > > correspond
> > > > to the respective "deleteUser" API call.
> > > >
> > >
> > > It's tricky, first you should get a full list of entities. It's a lot
> of
> > > hard work if you do it manually but you can do smartly if you use Api
> > > Discovery. There are more than 300+ APIs in CloudStack, now groupped as
> > per
> > > entities (see a package like org.apache.cloudstack.api.<entitiy>.<api
> cmd
> > > class>).
> > >
> > > So, first you need to classify the entities, get it checked (like write
> > > tests) and then define these operations. Few of us are inclined towards
> > > rewriting an API server that is RESTful and not query based. The
> > challenge
> > > there is to reuse present cmd classes, one way is to use reflections
> and
> > > another round of api annotations refactoring. Easiest way would be to
> > just
> > > fix/add/reuse Api Discovery, or write something use metaprogamming that
> > > auto generates your wrapper.
> > >
> > > I'm floating these ideas so you can think about it and come up with a
> > > strategy that creates maintainable, extendable code which would require
> > > less time to implement it.
> > >
> > > 2. A complete UI designed using Twitter Bootstrap and Backbone.js.
> > > > Obviously this will use the API that I'll be making.
> > > >
> > >
> > > +1 This is a fantastic idea, a better, faster, modular UI that is
> > > responsive is much appreciated and we will have an alternative to the
> > > default one.
> > >
> > > Avoid sending direct emails to anyone and feel free to reach out to the
> > dev
> > > ML, email like a boss™.
> > >
> > > Happy hacking!
> > >
> > > Cheers.
> > >
> > > (An app made using Bootstrap and Backbone.js:
> > > > http://coenraets.org/directory/ )
> > > >
> > > > Any suggestions/comments ?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-1778
> > > > [2] https://github.com/runseb/cloudstack-flask
> > > > [3]
> > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201304.mbox/%3C20130424083847.GA11354%40cloud-2.local%3E
> > > >
> > > > Thanks,
> > > > Shiva Teja.
> > > >
> > >
> >
>

Re: [GSoC] Introduction and Project Discussion

Posted by Rohit Yadav <bh...@apache.org>.
On Mon, Apr 29, 2013 at 1:53 AM, Shiva Teja <sh...@gmail.com> wrote:

> Hi Rohit,
>
> I think you made my work a lot easier :) I can use code from cloudmonkey to
> generate API cache and then build the code for the wrapper using it.
>
> I might need some information on this. How would a RESTful CloudStack API
> look like ?


This is a hard issue because the challenge is not just to implement
something, but something that will be maintainable. Your APIs are your
interface or contract to the outside world so once you give away your spec
to the outside world, you've the burden to keep backward compatibility and
not mess up when you do any kind of refactoring.

Some general rules I see are; all entities are nouns, the verbs are not
part of the url but how you call them; so list/read would be GET, create
would be POST, update would be PUT, remove/del would be DELETE... that said
you can create your own X- headers to mean something. People have written
books, gave talk on how to write good RESTful APIs.


> If I get these basic rules, I am guessing it shouldn't be tough
> to generate the wrapper.
>

The implementation won't be tough, but getting it right would be. Right now
I'm just splitting the apiname at the camelCase's hump in cloudmonkey, so
camel becomes a command and Case becomes the entity.


>
> Here's a very basic idea. I am using the same terminology used in
> cloudmonkey. In "listUsers", users is subject and list is the verb.
> In most of the cases the URL for an API command can be something like
> "baseurl/subject/verb" with an appropriately chosen HTTP method based on
> the verb. For some "verbs" like list, get, update, delete, add, it doesn't
> make sense to have them in the URL and using the appropriate HTTP method
> would mean the same. So I'll have to write the rules for each verb. These
> rules might contain method to be used for the verb, should the verb be in
> the URL or not...etc. And use these rules to generate the wrapper.
>

It's not straight forward, for example create/add/generate are few words in
apis which would be GET Apis in restful terms. One way would be to manually
sort/group the apis, other would be to annotate each api with an entity
name, RESTful type {one of GET, POST, PUT etc.} and parent (For example,
/zone/pod/cluster makes sense?).


> I am trying to decide these rules, so that they don't deviate from the
> point of being a RESTful API. Will get back with final implementation
> details before I finish my application for GSoC.
>

Lastly, talk to Sebastien or someone who would is participating in GSoC as
a mentor because it's important to identify who would mentor you if they
would, best of luck.

Cheers.
I'm skipping applying to being a GSoC mentor this year, pissed off from
GSoC admins this year. FOSS is just going to dogs; fck they did not include
one project that has no real company to back its development and really
needs help; VideoLAN/VLC.



> Regard,
> Shiva Teja(irc: teja)
>
>
> On Sat, Apr 27, 2013 at 10:14 PM, Rohit Yadav <bh...@apache.org> wrote:
>
> > Hi Shiva,
> >
> > On Sat, Apr 27, 2013 at 1:29 AM, Shiva Teja <sh...@gmail.com>
> wrote:
> >
> > > Hi all,
> > >
> > > I am Shiva Teja, an undergrad student from IIT Mandi, India. I will be
> > > participating in GSoC this year. I'd like to work on the new CloudStack
> > UI
> > > with bootstrap project[1]. I've been experimenting with API for the
> past
> > > few days. After reading a couple of blog posts by Sebastien, his recent
> > > hack on this[2] and a recent discussion[3] on the mailing list about
> > making
> > > CloudStack API RESTfull, here are the things I plan to do.
> > >
> >
> > Have you started working on your plan or just proposing? Hope you have a
> > setup and tried CloudStack on DevCloud. For starters I suggest you to
> > download, build and deploy CloudStack, play around APIs, cloudmonkey (a
> > CLI) and the API Discovery service because both of your idea proposals
> are
> > around APIs.
> >
> > 1. A more "human", RESTfull wrapper API on top of CloudStack API using
> > > Flask python framework. Something like "GET /users" will directly
> > > correspond to "listUsers" API command. "DELETE /user/<id>" will
> > correspond
> > > to the respective "deleteUser" API call.
> > >
> >
> > It's tricky, first you should get a full list of entities. It's a lot of
> > hard work if you do it manually but you can do smartly if you use Api
> > Discovery. There are more than 300+ APIs in CloudStack, now groupped as
> per
> > entities (see a package like org.apache.cloudstack.api.<entitiy>.<api cmd
> > class>).
> >
> > So, first you need to classify the entities, get it checked (like write
> > tests) and then define these operations. Few of us are inclined towards
> > rewriting an API server that is RESTful and not query based. The
> challenge
> > there is to reuse present cmd classes, one way is to use reflections and
> > another round of api annotations refactoring. Easiest way would be to
> just
> > fix/add/reuse Api Discovery, or write something use metaprogamming that
> > auto generates your wrapper.
> >
> > I'm floating these ideas so you can think about it and come up with a
> > strategy that creates maintainable, extendable code which would require
> > less time to implement it.
> >
> > 2. A complete UI designed using Twitter Bootstrap and Backbone.js.
> > > Obviously this will use the API that I'll be making.
> > >
> >
> > +1 This is a fantastic idea, a better, faster, modular UI that is
> > responsive is much appreciated and we will have an alternative to the
> > default one.
> >
> > Avoid sending direct emails to anyone and feel free to reach out to the
> dev
> > ML, email like a boss™.
> >
> > Happy hacking!
> >
> > Cheers.
> >
> > (An app made using Bootstrap and Backbone.js:
> > > http://coenraets.org/directory/ )
> > >
> > > Any suggestions/comments ?
> > >
> > > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-1778
> > > [2] https://github.com/runseb/cloudstack-flask
> > > [3]
> > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201304.mbox/%3C20130424083847.GA11354%40cloud-2.local%3E
> > >
> > > Thanks,
> > > Shiva Teja.
> > >
> >
>

Re: [GSoC] Introduction and Project Discussion

Posted by Shiva Teja <sh...@gmail.com>.
Hi Rohit,

I think you made my work a lot easier :) I can use code from cloudmonkey to
generate API cache and then build the code for the wrapper using it.

I might need some information on this. How would a RESTful CloudStack API
look like ? If I get these basic rules, I am guessing it shouldn't be tough
to generate the wrapper.

Here's a very basic idea. I am using the same terminology used in
cloudmonkey. In "listUsers", users is subject and list is the verb.
In most of the cases the URL for an API command can be something like
"baseurl/subject/verb" with an appropriately chosen HTTP method based on
the verb. For some "verbs" like list, get, update, delete, add, it doesn't
make sense to have them in the URL and using the appropriate HTTP method
would mean the same. So I'll have to write the rules for each verb. These
rules might contain method to be used for the verb, should the verb be in
the URL or not...etc. And use these rules to generate the wrapper.

I am trying to decide these rules, so that they don't deviate from the
point of being a RESTful API. Will get back with final implementation
details before I finish my application for GSoC.

Regard,
Shiva Teja(irc: teja)


On Sat, Apr 27, 2013 at 10:14 PM, Rohit Yadav <bh...@apache.org> wrote:

> Hi Shiva,
>
> On Sat, Apr 27, 2013 at 1:29 AM, Shiva Teja <sh...@gmail.com> wrote:
>
> > Hi all,
> >
> > I am Shiva Teja, an undergrad student from IIT Mandi, India. I will be
> > participating in GSoC this year. I'd like to work on the new CloudStack
> UI
> > with bootstrap project[1]. I've been experimenting with API for the past
> > few days. After reading a couple of blog posts by Sebastien, his recent
> > hack on this[2] and a recent discussion[3] on the mailing list about
> making
> > CloudStack API RESTfull, here are the things I plan to do.
> >
>
> Have you started working on your plan or just proposing? Hope you have a
> setup and tried CloudStack on DevCloud. For starters I suggest you to
> download, build and deploy CloudStack, play around APIs, cloudmonkey (a
> CLI) and the API Discovery service because both of your idea proposals are
> around APIs.
>
> 1. A more "human", RESTfull wrapper API on top of CloudStack API using
> > Flask python framework. Something like "GET /users" will directly
> > correspond to "listUsers" API command. "DELETE /user/<id>" will
> correspond
> > to the respective "deleteUser" API call.
> >
>
> It's tricky, first you should get a full list of entities. It's a lot of
> hard work if you do it manually but you can do smartly if you use Api
> Discovery. There are more than 300+ APIs in CloudStack, now groupped as per
> entities (see a package like org.apache.cloudstack.api.<entitiy>.<api cmd
> class>).
>
> So, first you need to classify the entities, get it checked (like write
> tests) and then define these operations. Few of us are inclined towards
> rewriting an API server that is RESTful and not query based. The challenge
> there is to reuse present cmd classes, one way is to use reflections and
> another round of api annotations refactoring. Easiest way would be to just
> fix/add/reuse Api Discovery, or write something use metaprogamming that
> auto generates your wrapper.
>
> I'm floating these ideas so you can think about it and come up with a
> strategy that creates maintainable, extendable code which would require
> less time to implement it.
>
> 2. A complete UI designed using Twitter Bootstrap and Backbone.js.
> > Obviously this will use the API that I'll be making.
> >
>
> +1 This is a fantastic idea, a better, faster, modular UI that is
> responsive is much appreciated and we will have an alternative to the
> default one.
>
> Avoid sending direct emails to anyone and feel free to reach out to the dev
> ML, email like a boss™.
>
> Happy hacking!
>
> Cheers.
>
> (An app made using Bootstrap and Backbone.js:
> > http://coenraets.org/directory/ )
> >
> > Any suggestions/comments ?
> >
> > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-1778
> > [2] https://github.com/runseb/cloudstack-flask
> > [3]
> >
> >
> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201304.mbox/%3C20130424083847.GA11354%40cloud-2.local%3E
> >
> > Thanks,
> > Shiva Teja.
> >
>

Re: [GSoC] Introduction and Project Discussion

Posted by Rohit Yadav <bh...@apache.org>.
Hi Shiva,

On Sat, Apr 27, 2013 at 1:29 AM, Shiva Teja <sh...@gmail.com> wrote:

> Hi all,
>
> I am Shiva Teja, an undergrad student from IIT Mandi, India. I will be
> participating in GSoC this year. I'd like to work on the new CloudStack UI
> with bootstrap project[1]. I've been experimenting with API for the past
> few days. After reading a couple of blog posts by Sebastien, his recent
> hack on this[2] and a recent discussion[3] on the mailing list about making
> CloudStack API RESTfull, here are the things I plan to do.
>

Have you started working on your plan or just proposing? Hope you have a
setup and tried CloudStack on DevCloud. For starters I suggest you to
download, build and deploy CloudStack, play around APIs, cloudmonkey (a
CLI) and the API Discovery service because both of your idea proposals are
around APIs.

1. A more "human", RESTfull wrapper API on top of CloudStack API using
> Flask python framework. Something like "GET /users" will directly
> correspond to "listUsers" API command. "DELETE /user/<id>" will correspond
> to the respective "deleteUser" API call.
>

It's tricky, first you should get a full list of entities. It's a lot of
hard work if you do it manually but you can do smartly if you use Api
Discovery. There are more than 300+ APIs in CloudStack, now groupped as per
entities (see a package like org.apache.cloudstack.api.<entitiy>.<api cmd
class>).

So, first you need to classify the entities, get it checked (like write
tests) and then define these operations. Few of us are inclined towards
rewriting an API server that is RESTful and not query based. The challenge
there is to reuse present cmd classes, one way is to use reflections and
another round of api annotations refactoring. Easiest way would be to just
fix/add/reuse Api Discovery, or write something use metaprogamming that
auto generates your wrapper.

I'm floating these ideas so you can think about it and come up with a
strategy that creates maintainable, extendable code which would require
less time to implement it.

2. A complete UI designed using Twitter Bootstrap and Backbone.js.
> Obviously this will use the API that I'll be making.
>

+1 This is a fantastic idea, a better, faster, modular UI that is
responsive is much appreciated and we will have an alternative to the
default one.

Avoid sending direct emails to anyone and feel free to reach out to the dev
ML, email like a boss™.

Happy hacking!

Cheers.

(An app made using Bootstrap and Backbone.js:
> http://coenraets.org/directory/ )
>
> Any suggestions/comments ?
>
> [1] https://issues.apache.org/jira/browse/CLOUDSTACK-1778
> [2] https://github.com/runseb/cloudstack-flask
> [3]
>
> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201304.mbox/%3C20130424083847.GA11354%40cloud-2.local%3E
>
> Thanks,
> Shiva Teja.
>