Google Summer of Code 2009 Ideas
From Globus
Globus has been accepted as a Google Summer of Code 2009 mentoring organization. This page lists our proposed GSoC project ideas. The project ideas are grouped according to the Globus technology areas (common runtime, execution management, etc.). This list of ideas is by no means exclusive, so if you have a cool idea for a Globus-related project, please contact one of the GSoC mentors. There are also additional pages where you may be able to find inspiration for interesting summer projects.
Before submitting an application to GSoC with Globus as your mentoring organization, make sure you read our GSoC FAQ, which provides some pointers on how to write a successful application.
Once you are ready to submit an application, remember that you must do so before April 3rd through the GSoC webapp.
Common runtime projects
Java WS Core Monitoring and Management Tool
Globus project: Java WS Core
Description: One of the biggest requests from end users of the Java WS Core (directly or indirectly) is more support for monitoring, managing and debugging running server instances. Java provides a standard set of interfaces for creating management and monitoring components in JMX. The goal of this project is to leverage the JMX tools provided by the JRE to support monitoring of GT components by providing access to resource state, logging configuration, memory consumption and other information related to the running container.
The deliverables for this project would be:
- Standard JMX MBeans for GT Components.
- Scripting tool for common GT management tasks (based on Scala, Groovy, Clojure, for example).
- [Optional] A HTML/Javascript based tool for management tasks
Mentor: Tom Howe
Requirements:
- Strong Java Skills.
- Ideally an understanding of the JMX architecture
- Ideally experience with JVM based scripting languages
- Ideally a working knowledge of HTML and JavaScript
Data projects
PSK Globus XIO driver
Globus project: XIO
Description: The goal of this project is to create a Globus XIO driver that will accept or reject a connection opening based on a pre-shared key. And additional protocol will have to be added to verify, upon opening a connection, that each connection endpoint has the pre-shared key. How the key gets to each side is outside of the scope of the project. Research into what is the best security protocol to establish proof that the key is known by both sides will be a large part of this effort. Additional research into possible integrity and encryption techniques based off a pre-shared key will also be important.
The deliverables for this project would be:
- A short document describing what security protocols we will be using
- A Globus XIO driver implementing the security protocol
- [Optional] A performance study leveraging GlobusXIO Perf comparing the new security protocol to GSI
Mentor: John Bresnahan
Requirements:
- An interest in network security
- A basic understanding of PKI security infrastructure
- C programming
- A basic understanding of TCP
- A command of UNIX environments
Develop a new 'sync' feature for GridFTP client 'globus-url-copy'
Globus project: GridFTP
Description: The goal of this project is to add 'sync' feature (rsync like capabilities) to globus-url-copy, a commonly used GridFTP client. If this feature is enabled, globus-url-copy needs to check for the existence of a file at the destination before transferring. If exists, it needs to determine whether the source version is different from that of the destination and based on how much it has changed, globus-url-copy should optimize the transfer. Ideally, this should not involve any changes to the GridFTP protocol. So it involves research into developing a logic that does not involve any changes to the GridFTP protocol.
The deliverables for this project would be:
- New 'sync' feature to globus-url-copy that can be enabled through commandline
- A performance study to illustrate how and when this feature will be beneficial
Mentor: Raj Kettimuthu
Requirements:
- An interest in wide-area data movement
- C programming
- A basic understanding of FTP and rsync
- A command of UNIX environments
Profiling the new GridFTP server
Globus project: GridFTP
Description: The goal of this project is to do a full system profile of Globus GridFTP server, widely used data movement tool, and detail how time is spent in the server. It involves the characterization of the effect of transport protocol (TCP or UDT) used, buffer size, concurrency, block size, parallelism on data transfer rate and server CPU utilization. The idea is to understand the trade-off between single client performance and server load. Potentially, there could be some configurations that might improve the client performance and at the same time do not increase (or might even decrease) the server load. This project will identify such configurations (if any) and explain the reason behind that. Essentially, this work will enable users to configure and optimize their systems for better end-to-end transfer performance and higher throughput. This project involves the use of profiling tools such as oprofile to perform a full-system characterization including the path through the kernel with minimal impact to the system.
The deliverables for this project would be:
- A detailed report on how the time is spent on the GridFTP server side including a characterization of the fraction of time spent in the different parts of the system including the kernel.
- A detailed report on how different transport protocols and parameters such as buffer sizes, block sizes, parallel streams, concurrency affect the transfer rate and CPU utilization.
Mentor: Raj Kettimuthu
Requirements:
- A command of UNIX environments
- C programming
- Good operating systems background
- A basic understanding of FTP
Performance characterization of GridFTP on 10+ Gigabit networks using hosts with 10 Gigabit network interface cards
Globus project: GridFTP
Description: Network interface cards with data rates of 10 Gigabit/s is becoming prevalent. With the advent of multicore processors, it is feasible for a host to drive data transfers at 10 Gigabit/s. The aim of this project is to characterize the performance of Globus GridFTP servers on hosts with 10 gigabit network interface cards. As Globus GridFTP can use UDT as an alternate transport procotol for TCP, this project would characterize the performance using both (TCP and UDT) the protocols. The resource usage on the end systems would also be characterized as part of this study. TeraGrid, Teraflow testbed, testbeds in ESNet or Internet2 are some of the potential testbeds for this study.
The deliverables for this project would be:
- Characterize performance of GridFTP transfers over the wide area network using TCP as the underlying transport protocol
- study the performance of both memory-to-memory and disk-to-disk transfers
- apply optimizations such as parallel TCP streams
- compare the performance with benchmarking tools such as iperf
- Characterize performance of GridFTP transfers over the wide area network using UDT as the underlying transport protocol
- study the performance of both memory-to-memory and disk-to-disk transfers
- compare the performance with that of TCP
- Characterize the resource usage on the host at each end of the transfer
- A report and possibly a publication on this characterization study
Mentor: Raj Kettimuthu
Requirements:
- An interest in high speed networks
- A command of UNIX environments
- A basic understanding of FTP, network measurement tools, performance benchmarking
GlobusXIO Checksum
Globus project: XIO
Description: In this effort we will create a Globus XIO driver that will run a checksum on the data which is streaming through it. It will have two modes of operation:
- checksum the stream as data passes and report the final value on close. Each end of the connection will then verify the others sum in some out of band fashion.
- checksum each block that passes and send the it across the wire with the payload in a block header. If the sums do not match the connection is immediately closed.
The student will be responsible for investigating various checksum algorithms and writing the code in a modular so that different algorithms can be plugged in and compared.
Deliverables:
- A Globus XIO driver that reports the checksum of a data stream
- A Globus XIO driver that verifies a data checksum at a block level
- Documentation on how to use the driver and a comparison graph of the performance of different algorithms.
Mentor: John Bresnahan
Requirements:
- An understanding of checksums and their purpose
- C programming
- A basic understand of TCP
- A command of UNIX environments
Execution projects
GridWay + Google Maps mashup
Globus project: GridWay
Description: GridWay users retrieve information about the Grid resources they have access to and their jobs using the commands gwhost and gwps. Even if the given information is complete, a Command Line Interface doesn't provide the user the big picture of what's going on. If a picture is worth a thousand words, a GoogleMap will be worth a million. The objective is to provide a wrapper to these commands and use the GoogleMaps API to represent geographically the Grid activity.
Mentor: Alejandro Lorca
Develop a GUI for GridWay
Globus project: GridWay
Description: GridWay provides its users with a complete and powerful set of commands for job submission and monitoring. However, not all users are made for a Command Line Interface, so GridWay is asking for a neat Graphical User Interface. With this GUI, users should be able to compose and manage their jobs. There isn't a preferred technology for this implementation (GTK+, Qt, Java, ...) so a reasoned choice would be accepted.
Mentor: Jose Luis Vazquez-Poletti
Integration of cloud resources into a local scheduler
Globus project: Nimbus/Virtual Workspaces
Description: Infrastructure-as-a-Service compute clouds (such as EC2 or the Science Clouds) allow users to obtain an environment on an “as needed” basis. One interesting way to use them is to extend an existing job scheduler such as PBS/SGE/Condor/Alien so that new platforms are added to the pool managed by the scheduler based on need. The goal of this project is to develop/extend such system and evaluate it.
The deliverables for this project would be:
- Implementation of extensions of the selected job scheduler and relevant tools
- A thorough testing and evaluation of the resulting system, including failure rates, etc.
Mentor: Kate Keahey
Requirements:
- Solid system skills, experience with distributed and job management technologies
- Ideally familiarity with virtualization and cloud computing
ClusterBuilder: Distributed Virtual Environments over the Clouds
Globus project: Nimbus/Virtual Workspaces
Description: The Science Clouds provide a testbed on which distributed virtual clusters can be created. Today, we create these clusters manually by provisioning resources on various clouds, potentially putting a network overlay over those resources, etc. This project will develop a service to automate this process by (1) obtaining availability information from different clouds, (2) provisioning resources on the clouds based on that information, (3) contextualizing them, (3) integrating them with overlays and other technologies to obtain the final cluster.
The deliverables for this project would be:
- Implementation of ClusterBuilder as well as clients providing various “levels” of functionality (e.g., including contextualization or not, including overlays or not, etc.)
- A testing and evaluation of the resulting system, etc.
Mentor: Kate Keahey
Requirements:
- Solid system skills, experience with distributed and job management technologies
- Ideally familiarity with virtualization and cloud computing
Extending the Generic Taverna based Workflow Service
Globus project: Not tied to a particular Globus project, but involves writing Globus-based code for caGrid
Description: caBig (cancer Biomedical Informatics Grid) aims to bring together disparate data and analytic resources into a “World Wide Web of cancer research. These data and analytical resources are exposed as grid services within the caGrid framework. The key to the realization of the benefits of these grid services is the ability to integrate basic services in the form of scientific workflows to create higher-level applications. Each workflow can represent a specific scientific goal.
Currently, caGrid provides a Taverna based workflow execution-service where the Taverna’s execution engine is wrapped into a Web-service. And it also provides a plugin within Taverna Workbench (client interface) that allows users to create workflows and submit them to the execution-service.
We want to create a tool that would basically extend this generic workflow execution service into a specific scientific workflow based service and deploy/host it on a remote host within a Cloud (on Amazon EC2 or Nimbus) infrastructure. This would allow users to use these deployed workflow services as individual components within larger workflows. These services would be using the WS-Resource Framework (WSRF).
At the end of the project, the tool should host a few workflows as services in the Cloud and create a larger workflow using these services and submit it to the generic workflow service.
Links related to this project:
- http://www.cagrid.org/wiki/Workflow_Services
- http://www.mygrid.org.uk/tools/taverna/taverna-2-0/
- http://en.wikipedia.org/wiki/Web_Services_Resource_ Framework
Mentor: Dina Sulakhe and Wei Tan
A Taverna plug-in for easy access of cancer research data
Globus project: Not tied to a particular Globus project, but involves writing Globus-based code for caGrid
Description: A primary motivation of caBIG is the sharing of cancer research data over multiple research institutions all over US. In order to do that, caBIG proposes a query language called CQL (Common/caGrid Query Language, see http://wiki.cagrid.org/display/dataservices/CQL) for all caGrid data services (http://wiki.cagrid.org/display/dataservices/) to express queries against a data source using an object oriented language. caGrid data services are frequently used inside caGrid workflows modeled using Taverna workbench. However, CQL is hard to construct by end users who are with limited IT expertise. This proposal is going to provide a Taverna plug-in that ease the construction of CQL and eventually the use of caGrid data services. The functionalities of this plug-in include:
- Retrieve the metadata of target caGrid data service so that users are aware of what kind of data they can get.
- A GUI that allows users to express their needs in data query (which data is needed, with what criteria, etc), transforms the users’ requirement into CQL and send to caGrid data services.
- A intelligent helper that detects the syntactic and semantic similarity among the input/output of data services and give user suggestions on how to connect these services when a workflow is going to uses these services in a pipeline.
This plug-in is a great help to cancer researchers to focus on their business (what data they want, how to feed the result of one task into its subsequent tasks, etc), instead of the implementation details behind it.
Requirements:
- An interest in workflow, Web service, and GUI development.
- Java programming.
Mentor: Wei Tan and Ravi Madduri
AJAX GUI for Taverna and comparison with other tools on pipeline modeling/execution
Globus project: Not tied to a particular Globus project, but involves writing Globus-based code for caGrid
Description: The combination of Web Services and scientific workflow technology has made it more convenient for scientists to leverage available data and computational resources, streamlining data processing and exploration, in a Web-scale manner. We are going to investigate the application of various workflow tools, like Taverna (http://taverna.sourceforge.net), Yahoo pipes (http://pipes.yahoo.com/pipes/) and SciencePipes (http://sciencepipes.org/), in cancer grid (caGrid, http://www.cagrid.org/), a service-oriented scientific collaboration platform.
Deliverables of this project will be:
- Implementation of several typical caGrid workflows implemented with Taverna, Yahoo pipes, and SciencePipes, respectively.
- A prototype of a AJAX based Taverna GUI to write pipelines.
- Comparison on the usability of these tools and the runtime issues like execution performance, scalability with large data, etc.
Requirements:
- An interest in workflow, Web service, and GUI development.
- Java programming, especially in AJAX and Web services.
- Basic knowledge in Grid computing.
Mentor: Wei Tan and Ravi Madduri
Creating a Client side GUI for Advance Reservations in the Grid
Globus project: GARS (Globus Advance Reservation Service)
Description: GARS provides a service to create and manage advance reservation of compute nodes using Local Resource Managers (LRMs) that include advance reservation support (such as Moab, Catalina, Maui, etc).
We want to create a cool-looking client side GUI or an AJAX web interface that would allow users to create and manage their advance reservations on the Grid sites such as Teragrid sites. The GUI should provide Google calendar like interface from where users can schedule their reservations and also view any existing reservations with all the details of the reservations. The interface could automatically generate iCal or Google calendar events for the reservations. The client would also require GSI Security support.
Mentor: Dina Sulakhe
Creating a REST-based service for GARS
Globus project: GARS (Globus Advance Reservation Service)
Description: GARS provides a service to create and manage advance reservation of compute nodes. Currently GARS is implemented within a WS-Resource Framework (WSRF). We would like to create a new Rest based service for GARS using the existing Adapter code that actually creates and manages the reservation. This would be an interesting project, as we need to handle the various WSRF specific implementations such as Resource properties and stateful resources into a Rest based architecture. We currently don’t have an exact implementation plan and we may have to explore all other options. The motivation behind this project is to create a non-WSRF based version of this service.
Mentor: Dina Sulakhe
Implement GRAM protocol using XIO HTTP driver
Globus project: GRAM
Description: GRAM provides a network-visible service to create and manage jobs running on any of a number of local resource managers (Torque, Condor, SGE, etc). GRAM uses a limited subset of the HTTP protocol for its network interface, and is implemented using a legacy API (globus_io). We would be interested to see if this HTTP-based protocol could be implemented on top of the Globus XIO HTTP driver which processes a much larger subset of the HTTP protocol. A good first step would be to implement a wire-compatible GRAM client using the XIO http driver. If that proves possible, future work could be to implement the GRAM Protocol API using the XIO http driver. The motivation behind this project is to be able to eventually use some modern HTTP features as extensions to the GRAM protocol such as HTTP persistence and pipelining.
Mentor: Joseph Bester
Swift project
Adding functional operators to SwiftScript
Globus project: Swift
Description: the SwiftScript programming language has, over time, acquired quite a functional feel. To fit in with that, it would be interesting to have operators such as map, reduce, fold and unfold. This would be good for someone interested in programming language implementation
Mentor: Ben Clifford
Swift Log Analysis
Globus project: Swift
Description: Swift generates copious volumes of log output in several formats. There is a log-processing package which is a motley collection of shell scripts and perl scripts, which are both slow and error prone. So, some of these could be done:
- Rewrite large parts of this processing package, faster and better behaved.
- More interesting analyses of Swift behaviour could be implemented
- Some interactive log processing tool could be written (eg a java GUI instead of a set of statically generated webpages, as is generated now) - might be interesting for someone with an interesting in UI design / human-computer interaction and/or in debugging systems.
Mentor: Ben Clifford
Improving scheduling and site selection in Swift
Globus project: Swift
Description: The execution engine of Swift has a fairly simple scheduling system, which sends tasks for execution in the order in which the language processing engine generates them, and fairly naïvely picks which site to run on. This is not always optimal. There are a number of changes that could be made, for example:
- Changing ordering of execution of swift-level jobs based on how many other swift-level jobs depend on that first job
- reordering stageins and stageouts so to allow (in addition to the present as-they-come (I think) policy) "prefer stageins" (which would get more jobs going sooner, but incurring an expense in that stageouts would happen slower, and in our present restart model reduce the speed as which jobs complete enough for restart), and "prefer stageouts", which would get completed results out to submit side faster, at the expense of job execution speed.
- At present each site is given a single score, which goes up on success and down on failure; this score is used to determine how much load to send to a particular site. In some cases, a particular kind of job (such as a particular application) may work well on one site, and poorly on another; in such cases it would be useful if Swift could track scores per-site-per-app in addition to solely per-site.
- Make site selection aware of data placement on sites - when choosing sites, prefer those that already have input data files in order to reduce the amount of data transfer necessary.
Mentor: Ben Clifford
CoG execution and file transfer providers
Globus project: Swift
Description: The Java CoG kit provides execution and file transfer providers to interface software such as Swift to a range of data transfer and execution systems. New providers could be written to allow Swift to submit tasks through some existing job or transfer mechanism. Two ideas that are particularly relevant to Swift at present are job submission through Condor(-G), and job submission through the GRAM LRM interface (so that CoG could submit to GRAM jobmanagers without needing a local GRAM installation.
Mentor: Ben Clifford
Mechanical turk
Globus project: Swift
Description: Interface Swift to the Amazon Mechanical Turk so that portions of a Swift run can be farmed out to human slaveworkers. There's no concrete use case for this - its more a "ha, that's neat" idea.
Mentor: Ben Clifford
Swift Replica Location Mapper
Globus project: Swift
Description: A mapper in Swift translates an in-program variable reference to a URI (commonly to a file on disk, or to a file on a gridftp server). One idea that I'm interested to see in practice is to perform that mapping using the Globus Replica Location Service, so that parameters to the mapper would specify some RLS logical filename or pattern for logical filenames, that would be mapped into Swift data structures.
Mentor: Ben Clifford
Swift run progress summarisation and visualisation
Globus project: Swift
Description: People are often interested in knowing how far their Swift run has got. At present, Swift prints a progress line every few seconds listing how many jobs are in each state. However, progress could be summarised in various different ways: for example, an output of the program listing annotated with the execution progress of each line of code; a graph with red/yellow/green progress indication; on-going text based reports of progress summarised by execution site or by application name, rather than by job state. There are probably other ideas too.
Mentor: Ben Clifford
Swift/gLite integration
Globus project: Swift
Description: It would be nice for Swift to run on gLite-based grids. I've done some work towards this already, on the file management side of things; but at present Swift cannot submit jobs into gLite's workload management system. This project would be to write the necessary code to make that happen (probably mostly a CoG execution provider), so that at the end of the project, Swift programs can run on gLite-based grids. In order to work on this project you probably need prior experience working with gLite, and access to some existing gLite installation (I can help you get up to speed on Swift, but can't really help with gLite)
Mentor: Ben Clifford
Security projects
An Interceptor for Holder-of-Key SAML Assertions
Globus project: GridShib
Description: Recent events suggest that SAML-based authorization tokens will become widely available in X.509-based Grids. For instance, VOMS has recently added a SAML interface so users now have a choice regarding token formats (SAML or X.509). Profiles emerging from the OASIS Security Services (SAML) Technical Committee suggest that the notion of holder-of-key SAML assertion is maturing, so we can expect to see additional sources of holder-of-key SAML tokens in the near future.
Use Case. An end user uses an enhanced version ofvoms-proxy-initto obtain a signed holder-of-key SAML token from a SAML-enabled VOMS server. Usinggridshib-proxy-bind, the SAML token is bound to a proxy certificate signed by the user's trusted X.509 end-entity certificate, which is later presented to a grid service provider. The grid service provider authenticates the user as usual and confirms the subject as indicated in the holder-of-key<saml:SubjectConfirmation>element in the token, that is, by requiring the user to prove possession of the private key corresponding to the public key bound to the proxy certificate, and by comparing the subject DN bound to the end-entity certificate to the subject DN bound to the SAML token.
The goal of this project is to implement a GT 4.2 Policy Information Point (PIP) that intercepts, validates and parses a SAML V2.0 holder-of-key assertion. The PIP then populates a security context with the parsed SAML content.
A holder-of-key SAML assertion usable in the Grid is necessarily signed by its issuer. The PIP will verify the signature using a key retrieved from SAML metadata.
According to the OASIS SAML V2.0 Holder-of-Key Assertion Profile, a SAML issuer may bind one or more of the following elements to a SAML holder-of-key assertion: 1) <ds:X509SubjectName>, 2) <ds:X509SKI>, 3) <ds:X509Certificate>, 4) <ds:X509IssuerSerial>. As the relying party, the PIP will support one or more of these subject confirmation methods, in the priority order listed.
Links related to this project:
- VOMS and VOMS-SAML
- OASIS SAML V2.0 Holder-of-Key Assertion Profile
- GT 4.2 Authorization Framework
- OpenSAML Project
Requires: A solid understanding of XML technology is required; knowledge of SAML is a plus. Since both OpenSAML and the GT Authz Framework are implemented in Java, moderate to strong programming skill in that language is required.
Mentor: Tom Scavo
An Interceptor for GridShib CA-issued SAML Assertions
Globus project: GridShib
Description: The GridShib CA issues short-lived grid credentials to browser users via a Java Web Start application. Users authenticate to the GridShib CA using Shibboleth, a SAML-based, cross-domain, federated identity solution from Internet2.
Use Case. A user obtains an end-entity certificate from the SAML-enabled GridShib CA. As a consequence of SAML Web Browser SSO, the GridShib CA is presented with a signed SSO assertion, which is used to create a security context for the user. The GridShib CA binds a self-issued, holder-of-key SAML token to the end-entity certificate. The SSO assertion is nested inside the <saml:Advice> element of the self-issued X.509-bound SAML token and is forwarded (i.e., proxied) to a grid service provider for the purposes of access control. The grid service provider validates the end-entity certificate as usual (i.e., using X.509 certification path validation) while the authentication context asserted in the SSO assertion is used for access control at the resource.
The goal of this project is to implement a GT 4.2 Policy Information Point (PIP) that intercepts, validates and parses an X.509-bound SAML token issued by the GridShib CA. In particular, the PIP will consume the signed SSO assertion forwarded by the GridShib CA. The PIP will verify the signature using a key retrieved from SAML metadata and populate a security context with the parsed SAML content.
Links related to this project:
Requires: A solid understanding of XML technology is required; knowledge of SAML is a plus. Since both OpenSAML and the GT Authz Framework are implemented in Java, moderate to strong programming skill in that language is required.
Mentor: Tom Scavo
Distribution projects
Enabling RPM packaging of the Globus Toolkit
Globus Project: Globus Toolkit (at-large distribution project)
Description: Mattias Ellert has identified a couple of bugs that prevent the Globus Toolkit from being distributed as RPM packages. The goal of this project is to address these bugs (e.g., http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=6229 and https://bugzilla.redhat.com/show_bug.cgi?id=453847) to enable distribution of Globus as Fedora RPMs.
Mentor: None assigned.
"Blue sky" ideas
The following are "blue sky" project ideas. They are not as detailed as the above project proposals, and some of them might not even be feasible during a single summer. However, they could end up being the seed from which a really cool project springs.
- Write Windows client libraries for all the Globus Toolkit services. Ravi Madduri
- MSN Passport integration to X509. Ravi Madduri
- Create cool AJAX web interfaces for Globus Toolkit services. Ravi Madduri
- Integrate AccessGrid ( www.accessgrid.org) with the Globus Project. Ravi Madduri
- Grid Job Submission and Management from a hand-held (like iPhone, BlackBerry etc). Ravi Madduri
- Create OS X, Yahoo Widgets for Grid Service clients Ravi Madduri
Other sources of project ideas
The above list of project ideas is by no means exclusive. You may find inspiration for other cool ideas in the following places:
- Our mentors. Feel free to contact any mentor whose field of interest matches your own. If you are unsure of who to contact, or no mentor seems like a good match, please contact Globus GSoC administrators, and they will put you in touch with the right person.
- Bugzilla enhancement requests. Our bugzilla server includes a lot of enhancement requests that users and developers have come up with. Some of them are large enough to be restated as a summer project.
- Development campaigns. The Globus Alliance has several active development campaigns, which are listed in our Bugzilla server. Some of these could be restated as a project, or can provide inspiration for projects that are complementary to a campaign.
- Project Ideas page. Some of the ideas in this page are taken from an existing page where Globus developers list ideas for interesting projects. In this GSoC page we have only listed those ideas that would make sense as a self-contained summer project, but the other ideas listed in Project Ideas may provide inspiration for additional projects.
Mentors
Our GSoC mentors (and their areas of expertise) are:
- Ben Clifford: admin. grid workflow. programming languages.
- Ravi Madduri
- Tom Scavo: Grid Security, SAML
- John Bresnahan: GridFTP, Globus XIO
- Tom Howe: Java WS Core
- Alejandro Lorca: GridWay
- Jose Luis Vazquez-Poletti: GridWay
- Kate Keahey: Nimbus
- Raj Kettimuthu: GridFTP
- Dina Sulakhe: GARS (Globus Advance Reservation Service)
- Wei Tan
- Borja Sotomayor: Resource management with virtual machines, cloud computing
- Joseph Bester
If you have an idea for a project, but none of the above mentors seem like a good match, please contact the Globus GSoC administrators and they will try to match you to an adequate mentor.
Project idea guidelines
This section is intended only for mentors who want to propose new project ideas for students.
The GSoC FAQ has the following to say about project ideas:
An "Ideas" list should be a list of suggested student projects. This list is meant to introduce contributors to your project's needs and to provide inspiration to would-be student applicants. It is useful to classify each idea as specifically as possible, e.g. "must know Python" or "easier project; good for a student with more limited experience with C++." If your organization plans to provide an application template, you should include it on your Ideas list. Keep in mind that your Ideas list should be a starting point for student applications; we've heard from past mentoring organization participants that some of their best student projects are those that greatly expanded on a proposed idea or were blue-sky proposals not mentioned on the Ideas list at all.
Thus, we ask that you include the following information when proposing a new idea:
- Globus Project: What project (in the dev.globus sense of the word) does this idea relate to?
- Description: Include a 1-2 paragraph description of what has to be accomplished in this project. You do not need to completely specify the project, just give prospective students a good idea of what work is required (is it mainly development? will it involve a lot of independent research? is it easy or hard? etc.). Also, note that ideas don't necessarily have to be concrete tasks ("Add support for protocol FOO in component BAR") but can also be "blue-sky" ideas (e.g., "GridFTP is not currently capable of dealing with the latencies involved in transferring large files to Mars. Solve this."). In fact, Google encourages that we include a couple of these since they usually lead to the most interesting projects.
- Links (Optional): Websites or papers related to this project. For example, if you want a student to implement an idea you proposed in a paper, include a link to that paper.
- Requirements: What specific skills are required to do this project. (languages, knowledge of protocols, should they already be familiar with GT4 or is on-the-job training ok?, etc.)
- Mentor: Each project must have a mentor. The mentor is in charge of supervising students, tracking their progress, answering questions about the project, etc. If you would like to be the mentor for this project, please include your name and e-mail address here. If not, please leave this field blank, and we will assign a mentor from the mentor pool.
If you need additional inspiration on how to write up your idea, take a look at last year's project ideas.
