UC-KnowARC

From EGI Knowledge Base

Use Case title: Build European Grid infrastructure based on Grid middlewares from different providers

Short description: A user community wishes to share their existing resources via European Grid infrastructure. By the nature of the community specifics, these resources are already equipped with Grid middleware that suits this community most, and they do not intend to re-configure the resources, primarily because there is no manpower and the learning curve for any new middleware is very steep and takes time, all of which incurs unbearable costs, while the community hopes to reduce such, by joining EGI. The community then approaches EGI and requests to be accepted, much like a new domain joins Internet, or a new mobile operator is registered. EGI verifies that the community resources are compliant with international (e.g. OGF, IEEE) standards and satisfies EGI policies, and proceeds with including this set of resources into the infrastructure, no matter what middleware flavor or hardware is involved – just like it does not matter what firmware a mobile phone has, as long as its external interfaces are standards-compliant. As a result, the infrastructure consists of standard segments delivered by different manufacturers/providers, exactly like any other European infrastructure. In order to address needs of different customers, and to allow for healthy competition leading to technology progress, European Grid infrastructure must develop mechanisms that guarantee the possibility of including any Grid resource, independently of its internal architecture and set-up. A resource that provides a set of standard Grid interfaces and a number of functionalities that are needed by a user community.

Actors involved: User community (VO), possibly national Grid infrastructures, EGI operators, EGI security officers, possibly international standardization body, possibly funding bodies, possibly middleware providers.

---

Related Requirements:

• The procedure must be quick and drain no significant additional resources from the community
• EGI must not require installation of any specific software at community resource
• in case the community middleware is found to be non-compliant, community must have a freedom of selecting another middleware (a list with more than one suggestion from EGI is welcomed).

Pre-conditions:

• The community must have a working Grid structure already, not yet affiliated with EGI
• EGI must embrace international standards and develop a set of acceptance criteria based on them (not on de-facto standards of individual Grid players)
• EGI must have the corresponding administrative structure in place, that accepts and processes applications in a speedy manner

Steps:

1. User community (eventually organized as a VO) contacts EGI via an authorized representative (e.g. VO manager, if such exists, or a national Grid project coordinator etc.)
2. EGI officers provide a check-list of criteria that must be satisfied (including required OGF profiles, interfaces, policies)
3. User community provides evidence that the criteria are met
4. EGI and the User community in question exchange the necessary information to enable resource inclusion (service contact points, authorization details, signed agreements etc)

Post-conditions: The new resource enjoys operational benefits of being a part of EGI even when running a middleware of their own choice; EGI is obviously not required to offer any middleware support – this lies with middleware providers.

Projects involved: EGI, OGF, IGTF, national and international Grid development and deployment projects, any middleware provider

Middleware: Any middleware

Applicatons: All kinds of appliations