Grid Operations in EGI / NGIs The EGI mw function

1. Grid Operations in EGI / NGIsThe EGI mw function Panagiotis Louridas, GRNET Tomasz Szepieniec, CYFRONET Report from the 1st Session Rome, 13-14 March 2008

2. Grid Operations • To answer this question, we need a much better idea of what “the EGI Grid” will be… Is it: • A large-scale, production Grid infrastructure – build on National Grids that interoperate seamlessly at many levels, offering reliable and predictable services to a wide range of applications, ranging from “mission critical” to prototyping and research? • A loosely coupled federation of NGIs with little or no cross-grid activity, heterogeneous and sometimes incompatible middleware stacks, no cross-grid accounting, no need for coordinated operations or management

3. Principles • It’s rather clear that we are building EGI according to the 1st option • if we have international collaboration between scientists, we simply need an international infrastructure • but, many types of SLAs are needed • also inside NGIs • SLAs should be visible for end-user • EGI is constituted by NGIs, • not VOs or participating sites, • it promotes a multi-level operational model, without prescribing which services belong to which level

4. Costs • Cost of operation services for a NGI on EGI level should be lower than done by the NGI itself • How to fund central operation in EGI • Funded by NGIs on service basis • Co-funding from EU possible • VOs are important for requirement but are not considered as (direct) co-funder;VO should go thought NGIs • The presented costs: • needs new iteration • functions needs better explanation • EGI will find person to help NGI to understand functions in questionnaires

5. Other comments • ‘Low cost of entry’ is a challenge that we need to face • Transition period: • is needed, while EGI is different from EGEE • possibility to federate some operational services (like in some ROCs) • decision and funding from NGIs • Integrated operation does NOT impose a single middleware stack

6. Middleware • Key proposals requiring NGI feedback • Coordination of EU mw efforts and full service interoperability at EU and international level require an EGI mw function • The EGI mw function must continue to evolve and drive the 3 EU stacks (ARC, gLite and UNICORE) towards full interoperability between themselves and Internationally • An EU build/test system is an important service to favour EU mw coordination and convergence • The necessary efforts in EGI should continue to be co-funded by the EU commission • Grid project submitted to a call reserved to NGIs and EGI.Org • mw Consortia responsible for the technical developments • The EGI mw function should be the unique place in Europe where the future developments of mw for the EU e-Infrastructure will be planned and coordinated • What is needed to be done is prioritized by a Technical group formed by Middleware, Application and Operation functions

7. Two main ways for MW future • Stack-driven • for EGI it is crucial that a middleware exists and it's maintained • EGI should continue to be co-funded by the EU commission including mw Consortia responsible for the technical developments • currently interfaces specifications are partial; it is very hard to improve this • we have limited time to improve this • Service-driven • Better to focus on services and then find providers that could offer them • Should promote an open model that would generate competition which naturally generates better quality • It is restrictive to focus on these 3 mw stacks • eg., there is a lot of Globus development in Europe or • separated components e.g D-Cache www.eu-egi.org

8. Ideas to converge • Transition process • VOs are running, so support for existing middleware stacks should remain • There are projects that support MW maintenance for next two years • EGEE-III timeframe could be used to make an idea of open services less ‘phantomatic’ • Target model: well-defined services, open for competitive development • Service specification and verification should be vital functions of EGI • It is very important to have the user community in the improvement circle

9. Other comments • Alternative solutions: • continue gLite development in open source community • commercialise gLite • focus on user interface only and converge on this • Requirements and verification activity should be separated from middleware development • Inclusion of mw development in an infrastructure project needs very good justification

10. Middleware Issues • Who will pay for middleware development in target model? • Who will define services, interfacesand specifications? • EGI ?