RUS: Resource Usage Service Steven Newhouse James Magowan

Agenda Welcome & Introduction Charter & WG Goals Review of Grid Resource Usage activities  UK e-Science: The Level 2 Grid  … Recording Resource Usage  Service interface overview - define functionality not specifics.  Define contents of XML  [ Detailed definition of these can be postponed to post GGF on the list ] Extraction of Resource Usage Information  Service interface overview - define functionality not specifics.  Discuss security model for extracting data (Who can access what of whom?) Way ahead...

OGSA Resource Usage Service (RUS) Chairs:  Steven Newhouse  James Magowan Admin:   Mailing list: Met at GGF 6 Define an OGSA Resource Usage Service (RUS) that will track resource usage:  Define a service interface to add & search stored accounting records.  Define a security model for the data stored within the RUS  To support a (minimal but extensible) set of commonly understood attributes to describe resource usage (from the Usage Record WG).

Charter To define a Resource Usage Service (RUS) for deployment within an OGSA hosting environment that will track resource usage (accounting in the traditional UNIX sense) and will not concern itself with payment for the use of the resource.  Definition of service interface to add & search records for accounting information to support use by grid services, individual user clients or service managers.  Defining a security model for the data stored within the RUS, that protects and individuals right to privacy relating to how they used a service, by building upon the standard OGSA security infrastructure.  To support a (minimal but extensible) set of commonly understood attributes to describe resource usage (leveraging work undertaken by the Record Usage Format WG).

Charter: Goals & Milestones Goals  To enable the tracking of resource usage within Grid Services deployed within an OGSA environment. As the ‘resources’ that need to be tracked (e.g. CPU, time, memory) may be vary between services and over time an extensible schema will be used to structure this information. Milestones  GGF 5: Initiate discussion of this activity with a BOF and a move to produce a WG charter.  GGF 6: Contribute resource usage cases as GWD-I’s to build on existing information in this area within GGF.  GGF 6: Initiate detailed discussion on an initial specification of this service with the intention of producing a GWD-C that defines current activity and interfaces.  GGF 7: Present a revised specification for further discussion and continued iteration of the GWD-C.  GGF 8: Aim to complete the GWD-C with a proposed service specification and report on its use through a GWD-E. Examine current group activity with the intention of initiating a standard recommendation within a GWD-R.

Architecture OGSA Grid Service Service InterfaceService Data Service InterfaceService Data OGSA Chargeable Grid Service Grid Economic Service Interface Record Resource Usage OGSA Resource Usage Service Contract Negotiation Economic Service Data Contract Verification Service Charging OGSA Grid Banking Service Grid User

Interface Outline (1) Store Resource Usage  Resource Identifier (GSR?)  Sequence/Invocation Identifier (GSH?)  User Name (X.509 DN?)  When executed  Where executed (Human readable form of GSH)  What has been used?  Attribute & Value pairs (UR-WG/CRM-WG)  Schema based for resources? (CRM-WG)  Application invocation?  Comment Field?  Is this enough?  Need to have extensible attribute structure? Allow the undefined to be expressed!  Encapsulate as XML document.  UR-WG defines the content  Can the data be updated?  Update every 10 minutes… incremental updates of resources that are consumed  Do we always treat it as an incremental update or a new record (a failure?)  Upload document: Exception if not unique?

Interface Outline (2) What approach to use?  Expose the back end database using OGSA-DAI: expose structure not content  Expose the RUS content through the FindServiceData SDE’s  High-level service interface (new port type(s)) to extract RUS data that is implemented internally with, say, SQL commands. Restricts supported queries Extract Resource Usage  Return information relating to a specific service invocation  Return information relating to a particular service  Request Failure: Due to internal authorisation process  Options:  Return complete or partial record data? Query Resource Usage  On any attribute within the UR and the overall meta-data  EG:  Usage for a job  Usage for a particular machine  All those jobs using 4->16 processors.  Memory request greater than 16MB!

Interface Outline (3)  Do we handle charging? Allow updating – should the record be immutable?  Logging: Use OGSA logging to capture state transition to build RUS XML docs.  Is there lifetime to this data? Need a mechanism to purge records? But when?

Service Data Define who can store information in the service  By VO?  By Host Domain? Define who can extract information from the service  A user can extract their own job information  An administrator can access their own resources information  Allow general Define what information is stored  List the resource types stored by the service