EGEE is a project funded by the European Union under contract IST Grid Access Service Predrag Buncic JRA1 Meeting, Jun

JRA1 Meeting, June Introduction JRA1 Clusters  Integration  Testing  Information and Monitoring  Data Management  Workload Management  Security  Etc…

JRA1 Meeting, June Current gLite Prototype A Prototype Middleware on a testbed consists of  AliEn “shell”  Job submission: Alien CE->Condor-G->blaph->PBS/Condor Globus Gatekeeper  Data Management AliEn File & Metadata catalog AliEn SE with Castor & D-Cache SE with SRM gridFTP for transfers AliEn FTD Aiod/GFal RLS (EDG)  Security VOMS for certificate handling/SE gridmap files (NIKHEF) MyProxy for certificate delegation in GAS  GAS (Grid Access Service) Prototype with a few file cataloging functions  R-GMA & EDG WMS (not integrated yet) Extra Terrestrial Cluster [looking for help!]

JRA1 Meeting, June Talk Outline 1) API and Grid Access Service (GAS)  Why and how?  Service Controller (or Controller Service)? 2) GAS & Prototype (=>Pablo) 3) Package Manager  Why and how?

JRA1 Meeting, June API and GAS

JRA1 Meeting, June Starting from AliEn…

JRA1 Meeting, June Stepping stone: ARDA…

JRA1 Meeting, June Design team working document..

JRA1 Meeting, June Design team working document..

JRA1 Meeting, June DJRA1.1

JRA1 Meeting, June Client (application) side: API An API would be a library of functions used for building client applications, graphical user interfaces or even Grid Web portals (e.g. AliEn, Genius or Clarens). The API is used also to authenticate user to the Grid, let them submit jobs inquire job status and manage jobs access the files available on the Grid and put users files onto the Grid The application should be able to gain access files on the Grid by issuing requests to copy files to local temporary storage or via POSIX like interface to a near Storage Element.

JRA1 Meeting, June Server side: GAS The Grid Access Service (GAS) is the counterpart of the user API on service side and represents the user entry point to a set of core services.  Many of the User Interface API functions are simply delegated to the methods of the GAS. In turn many of the GAS functions are delegated to the appropriate service.  GAS service will be constructed out of Service Components that will in turn present a uniform public interface to underlying service.  The components from which the interface is constructed can be defined by the VO preferences at run time Grid Service Components Grid Service Component Library Construction specification Composition Logic Composition Type Message Dependency Interface specification MessagesOperations Grid Applications The Service Components are realized as a pluggable library with each component providing an interface to the specific middleware service. The intention was to define end user interface that allows them to interface their application to the Grid and keep this interface reasonably stable and protected from inevitable changes in the middleware.

JRA1 Meeting, June Grid Login Use Case The application then connects to the GAS Factory and passes over the secure line user name and password needed to get delegation of user credentials from the credential wallet. If this operation is successful, the GAS Factory will start a GAS service for the user and return the service endpoint. The application then connects to its endpoint and gains access to other Grid service. Many of the User Interface API functions are simply delegated to the methods of the GAS. In turn many of the GAS functions are delegated to the appropriate service. GAS service will be constructed out of Service Components that will in turn present a uniform public interface to underlying service. During its creation the user is authenticated and his rights for various Grid operations are checked against the Authorization Service. The GAS keeps the user credentials and authorization information. Before attempting to connect to the Grid, a user is expected to register his or her temporary credentials with VO independent credential wallet (like the NERSC secure MyProxy). As a first step in connecting to the Grid, the user application uses the API to connect to a configurable list of Configuration Services. These are the public services that can exist per VO or serve multiple VOs. They inquire VO configuration and Information Services as well as use DNS information to deliver initial configuration back to the user API

JRA1 Meeting, June Controller Service GAS lifetime will be restricted to the lifetime of delegated proxy credentials and will be managed by the Controller Service and user who will be able to destroy his own GAS instance. An instance of GAS should be created in a service environment in the proximity of the user (local site) where proper container has been located The GAS factory will ask Controller Service for appropriate service endpoint The Controller can decide to create local service or can contact another Controller

JRA1 Meeting, June GAS: Summary The GAS model of accessing the Grid is in many ways (authentication, proxy service) similar to various Grid Portals but it is meant to be distributed (the GAS Factory can start GAS in a service environment close to the user in network terms) and is therefore more scalable and resilient. As opposed to a traditional Web Portal, the GAS interface is more dynamics and reflects the role of the user in the system. The GAS is intended to be used by the application and not by the interactive user therefore it offers no presentation layer. The traditional Grid Portal can actually be easily constructed by specializing GAS into a Portal Service that will provide necessary content to a presentation layer provided by the Web Server. Similarly, the specialized application services can be constructed by extending GAS or providing appropriate Service Components. Grid services also have to be accessible directly using their respective mechanisms (i.e. not via the GAS). Package Manager Service

JRA1 Meeting, June Package Manager Service A Package Management Service is a helper service that automates the process of installing, upgrading, configuring, and removing software packages from a shared area (software cache) on a grid site. Explicitly requested by the users of a prototype This service represents an extension of a traditional package managment systems to distributed computational environment and it should use one of the estabilished package management systems as a backend. Some well-known examples of such systems include  RPM, Red Hat's package manager, used not only by Red Hat Linux but by several other Linux distributions.  dpkg/APT (used originally by Debian GNU/Linux, now ported to other systems).  Portage, used by Gentoo Linux and inspired by the BSDc ports system.  The ``ports tree'' system used by FreeBS NetBSD,OpenBSD and the like.  Pacman, package manager developed at Boston Univerity and used by several Grid projects (International Virtual Data Toolkit - iVDGL, Grid3)

JRA1 Meeting, June Basic assumptions The software is distributed in packages, usually encapsulated into a single file that contains metadata that describes the package's details, including its name, checksums, and dependencies on any other packages that it needs to work. It may also include information on how to configure the package for use and how to remove the package cleanly when it is no longer required. The package manager then uses this information to install, configure, and remove packages as requested by the user. The PM Service operates in the context of a VO and understands and resolves possible dependencies between the package versions provided by the V.O. administrator. This service is not responsible for the maintenance and deployment of middleware or system software components, unless the VO takes the responsibility to provide and maintain the middleware and/or system software as a part of the VO contributed software.

JRA1 Meeting, June Use case scenario In a typical scenario, the VO package administrator creates the binary package caches for one or more computing platforms, verifies and possibly digitally signs them. These caches are then published and made available for download via the PM Service. On the execution site, a local instance of PM Service will, on request from CE or JW, fetch and install binary packages into the local package cache. This local package cache should reside on a file system managed by the PM Service assuring that unused old packages are removed if disk space is needed to install newer versions. The existence of binaries can be advertised, thus minimizing download of packages from multiple locations. In this way, the PM Service could maintain the hierarchy of package caches to assure scalability and provide a fail-over capability. Access to VO packages should be controlled and possibly restricted and audited. The easiest way to achieve that is to treat the packages as any other File Catalogue entry and to apply common Authentication, Authorization and Auditing mechanisms. The integrity of individual packages should be verified by appropriate checksums. The package metadata information (including checksum information) should be retrieved from a trusted and certified VO site, independently from the package itself.

JRA1 Meeting, June Package Manager: Summary Service urgently required by users The software components needed for realization of such service exist Possible implementation scenario  Reworked AliEn Packman component exposed as a service using one (or more) of the package managers as a backend  Try to extract minimal package manager interface to allow alternative package manager backends  Personal preference: start with Portage Some prototyping needed

JRA1 Meeting, June Issues

JRA1 Meeting, June Issues  Configuration Service Discover VO services Bootstrap client application  Alternative transport and messaging protocols SOAP over IM protocol (Jabber) No need for incoming IP connectivity Service presence information as bonus Scalable asynchronous system logging (syslog)