airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject [GSoC] Project Proposals and how they change
Date Thu, 20 Mar 2014 19:07:50 GMT
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
Mime
View raw message