Grid Operations in EGI NGIs The EGI mw

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

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 2

Principles • It’s rather clear that we are building EGI according to the 1 st 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 3

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

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

Middleware • Key proposals requiring NGI feedback 1. 2. 3. An EU build/test system is an important service to favour EU mw coordination and convergence 4. 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 5. 6 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, g. Lite and UNICORE) towards full interoperability between themselves and Internationally What is needed to be done is prioritized by a Technical group formed by Middleware, Application and Operation functions

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 www. eu-egi. org separated components e. g D-Cache 7

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

Other comments • Alternative solutions: – continue g. Lite development in open source community – commercialise g. Lite – 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

Middleware Issues • Who will pay for middleware development in target model? • Who will define services, interfaces and specifications? – EGI ?