You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airavata.apache.org by Suresh Marru <sm...@apache.org> on 2014/03/20 20:07:50 UTC

[GSoC] Project Proposals and how they change

GSoC Students,

Its very nice to see good interest on Airavata gsoc projects and well thought out proposals. I just want to share the fact that "changes are inevitable". Google is expecting the mentors and organizations to provide opportunity for students to learn open source. And the modern day software development is very agile. So do not expect what you wrote in your plan is set in stone or will not change over the gsoc duration. Airavata is very agile and many disruptive changes happen, driven by architectural changes and community needs and input, its documented here - http://airavata.apache.org/development/roadmap.html

So the expectation from GSOC students is not to be guided by the proposal but to be guided by what is happening on this mailing list (and this is indeed how open source contributions work). If the project is approved, the community will give input on the priorities and your mentor is responsible for making sure you have the right direction and making sufficient contributions (google has designed a installment payment process to take care of not committed students). Over the next three months the development you will notice on Airavata is marching towards 1.0 release. You can look at this JIRA and its associated tasks to get a feel for what is needed - https://issues.apache.org/jira/browse/AIRAVATA-1000

Important major activities are:
* Finishing the thrift based API 
* Re-achitect Airavata Registry as per architecture mailing list discussions
* Design and Develop the Security mechanisms between Airavata Clients and Server and a trust layer between airavata server side components.
* Update all desktop and web user interfaces to adopt to the new API and as much as possible enable to directly work with thrift API Server. 
* Refine GFac architecture so multiple providers can co-exist. The architecture should be clean enough to allow seamless addition of new providers.
* Drop tight integration with EC2 and replace with JClouds so switching between any IAAS will be easy. Prototype with EC2 and Openstack. 
* Integrate all web interfaces into a co-ahesive Airavata Reference Web Gateway and integrate a pass through to third party identity stores.
* Add scheduling capabilities to Airavata which incorporates application specific monitoring.
* …others as they come in ..

Not all may be GSoC tasks, but I strongly encourage the students to contribute to them as your time permits.

Suresh