Changes between Initial Version and Version 1 of Raven3Q09QSR

10/13/09 14:55:58 (13 years ago)
Christopher Small



  • Raven3Q09QSR

    v1 v1  
     1= Raven Quarterly Status Report for Q3 2009 =
     3Reporting period: Jul 1 - Sep 30 2009
     5PI: John H. Hartman (University of Arizona)
     8== Major accomplishments ==
     10  * Support for creating Stork groups using !CoMon queries
     11  * Prototyped {{{raven}}} tool for one-step software installation
     12  * Ported Stork repository to mod_python infrastructure
     13  * Modified {{{sfa}}} authentication mechanism to explicitly sign arguments
     14  * Prototyped {{{owl}}}, a tool for monitoring slice health
     17== Description of work performed during last quarter ==
     19=== Activities and findings ===
     21 We developed {{{tempest}}}, an evolution of the {{{pacman}}} tool. {{{Tempest}}} separates group membership determination and package action determination into separate helper commands. This allows {{{tempest}}} to support the original {{{pacman}}} format for the groups and packages files, but also arbitrary programs that produce the proper output. For example, this allows {{{tempest}}} to make group membership decisions based on a !CoMon query, e.g. the user can specify a group based on a !CoMon query consisting of nodes that have more than a certain amount of free memory. Nodes individually and dynamically decide whether or not they belong in this group.
     23 We developed {{{raven}}}, a tool for one-step software installation. {{{Raven}}} greatly simplifies the process of deploying software packages on a slice. {{{Raven}}} creates a template directory tree that the user populates with the proper GENI key and software packages. {{{Raven}}} takes care of the rest, creating and signing the proper tpfiles and {{{tempest}}} files, and uploads these files to the Stork repository along with the packages. At that point Stork will install these packages on all nodes in the specified slice.
     25 We ported the Stork repository to the mod_python infrastructure of Apache. This allows the repository to take advantage of Apache's authentication and load balancing mechanisms.
     27 We modified the SFA authentication mechanism so that authentication is done by explicitly signing the request, rather than relying on the underlying SSL protocol for authentication. This greatly simplifies the design and implementation by decoupling authentication from the underlying transport protocol.
     29 We developed a prototype of {{{owl}}}, a service for monitoring slice health. {{{Owl}}} consists of an extensible set of client-side scripts that collect information about software running in the slice. This information is sent to a centralized {{{owl}}} server that stores the information in a database. The {{{owl}}} server makes this information available via Web pages as well as in XML and JSON format. We demoed {{{owl}}} at GEC5.
     31 We continue to work on {{{iftd}}}, a data transfer daemon that will allow Stork clients to access files via a variety of transport protocols such as http, ftp, !BitTorrent, and !CoDeploy. Protocol handling and error handling are encapsulated in the {{{iftd}}} daemon, freeing individual Raven tools from having to perform these functions. We anticipate deploying {{{iftd}}} in the next quarter and it will eventually replace the arizona_transfer  module the Raven tools currently use.
     34=== Project participants ===
     36  * John H. Hartman (University of Arizona)
     37  * Scott Baker (SB Software)
     38  * Justin Cappos (University of Washington)
     39  * Justin Samuel (University of Washington)
     40  * Jude Nelson (University of Arizona)
     42=== Publications (individual and organizational) ===
     44  *  None.
     46=== Outreach activities ===
     48  * None.
     50=== Collaborations ===
     52We worked closely with the following Cluster B members:
     53  * !PlanetLab -- Princeton University
     54  * GUSH -- Williams College
     56=== Other Contributions ===
     58  * None.