Raven Quarterly Status Report for Q1 2009

Reporting period: Jan 1 - Mar 31 2009

PI: John H. Hartman (University of Arizona)

Major accomplishments

• Participated in design and implementation of geniwrapper. Scott Baker has implemented major portions of the geniwrapper in preparation for our port of Stork to GENI.
• Added support for authentication via GENI GIDs to the Stork repository. This allows a user to log in and upload file based on his/her GID, rather than a PlanetLab login and password.
• Created a GENI-Compliant XMLRPC interface to the Stork repository and a command-line tool to allow automated uploading of files.
• Refactored and deployed Stork nest slice.
• Refactored and deployed Stork repository.
• Prototyped GUSH-based system for propagating Stork repository metadata updates to the Stork nest slice.
• Designed and deployed storksyncd, a daemon that keeps Stork repository metadata up-to-date in Stork client slices.
• Demonstrated a GUSH experiment that used Stork to install the software packages necessary for the experiment.

Description of work performed during last quarter

Activities and findings

We refactored the Stork repository so that it uses Apache and modpython to serve Stork packages and metadata. This greatly improved its security and load balancing. We also added functionality from the geniwrapper that allows users to authenticate themselves to the repository using a GID. We created an XMLRPC interface to the Stork repository to allow end-user tools to interact with the repository in an automated manner. A command-line tool extends the Princeton SFI tool to add an upload operation that uploads files to the Stork repository.

We refactored the Stork nest to remove functionality that is no longer needed by PlanetLab and GENI. This functionality allowed slivers to share files. This is no longer necessary and removing the implementation greatly simplified the nest.

We made significant progress towards a new GUSH-based mechanism for pushing Stork repository metadata to the Stork nest slice, rather than having each Stork client individually poll for the metadata. GUSH is used to push the metadata to the nest slice. A storksyncd daemon that runs in each client ensures that the metadata obtained from the nest is up-to-date, and if it is not it fetches the metadata directly from the repository. The storksyncd daemon is also used in the nest slice to fetch the metadata directly from the repository if the GUSH push mechanism fails. We have prototyped this system and are working to produce a production version.

Project participants

• John H. Hartman (University of Arizona)
• Scott Baker (SB Software)
• Justin Cappos (University of Washington)
• Justin Samuel (University of Arizona)
• Chris Floess (University of Arizona)
• Jude Nelson (University of Arizona)

Publications (individual and organizational)

• None.

Outreach activities

• None.

Collaborations

We worked closely with the following Cluster B members:

• PlanetLab -- Princeton University
• GUSH -- Williams College

Other Contributions

• None.