EDG ATF activities for 2003 and working towards an architecture for EGEE

1. EDG ATF activities for 2003 andworking towards an architecture for EGEE Bob Jones

2. March D6.6,8.3,9.3,10.3 evaluation reports (rescheduled) D7.6Security design report May EDG 2.0 release deployed subsequent improvements based on application feedback Project conference in Barcelona June D11.6Report of the 2nd annual conf. and industry Grid Forum workshop July D9.4EO application platform interface September EDG 2.x release deployed D1.6,2.5,3.5,4.5,5.5,6.7sw and doc. Final project conference in Heidelberg December D11.7Report on final project conference D11.9Report on contributions to international standards D1.7,2.6,3.6,4.6,5.6,6.8,7.7Final evaluation reports D8.4,9.5,10.4Application demos and final reports D12.19Third annual report Early 2004 Final project review 3rd year schedule final testbed

3. Current Activities for EDG ATF • Clarify EDG 2.0 architecture • Until end April • keep EDG 2.0 architecture model document up to date • meeting 15 & 16 April (CERN) • Work on “September release” architecture • Until End June • Update architecture model document • Meetings May 13 (Barcelona) & June 19 & 20 (Rome)

4. Work Load Management (WP1) Accounting Integrate cost estimation/accounting with scheduling policies Dependencies of jobs Using Condor DAGman mechanisms Job partitioning Relying on job “logical” checkpointing Resource reservation and co-allocation Depends on availability of reservable services in the testbed Integration between LB and WP3 R-GMA Allows advanced queries to LB Integration with WP2 query optimization services Software developments beyond EDG 2.0 (I) • Information & Monitoring (WP3) • More Producer types added • Complete Registry replication and extended Schema • Mediator enhancements • Complete trust-manager (WP2) integration and implement authorisation • Support multiple VOs (i.e. an info. sys. per VO) • Use Nagios as a visualisation tool on top of R-GMA. • Enumerate failure modes of the system and make the whole system robust. • Migrate to OGSA internally but with a wrapper to provide backwards compatibility.

5. Mass Storage (WP5) Data Transfer implemented in SE core Distributed SE for load balancing R-GMA Information providers VOMS integrate with SE for groups and roles Fine-grained access control using LCAS and LCMAPS Support for more MSS Sites relevant to WP8, 9 and 10 Posix I/O, Internal request queuing For reliability and predictability under high load More complete SRM v2.1 support Space reservation and quotas Data Management (WP2) Replication Pre- and post-processing Fault tolerant service Security VOMS support for all services (Authorization) Optimization Collection of usage patterns and testing of various algorithms Spitfire Generalization of interfaces for better manageability Software developments beyond EDG 2.0 (II)

6. Fabric Management (WP4) New components and enhancements foreseen: Installation and configuration: the new configuration, installation and node-management framework that replace LCFG(ng) Gridification: the local credential mapping service (LCMAPS) and fabric job repository Resource management: support for advanced compute resource reservations Fault tolerance: basic framework; support for global (inter-node) correlations Monitoring: alarm display; measurement repository interface to both Oracle and MySQL. Internal integration of all WP4 components together Software developments beyond EDG 2.0 (III) • Network (WP7) • Work with DANTE on network provisioning and QOS technologies • Diffusion of high throughput transfers solutions on testbed sites. • Enhancement of monitoring and of NetworkCost functions suite • Development of new visualization tools for end users and network administrators : • Presentation of data from R-GMA Archives containing all historical network metrics • Network topology analysis, based on PCP (Probe Coordination Protocol) and network paths.

7. Architecture for EGEE • EGEE project proposal being written now • Submitted to EU in first week of May • Initial feedback from EU by July • Assuming feedback is positive • Produce more detailed project plan for September/October • Assuming plan is accepted • Project likely to start 1st or 2nd quarter 2004

8. Proposed Plan for EGEE architecture work • Create a team to work towards an architecture for EGEE • Mandate: • Develop a grid-services architecture suitable for EGEE based on OGSA addressing the needs of the pilot application groups and taking into account experiences gained from EDG and related grid projects' activities during 2002 and 2003. • Involves members of EDG and other EGEE participants • Team should be of a similar size to ATF EDG

9. Proposed schedule • Agree team mandate & members by May 2003 • Work out requirements for basic grid infrastructure based on EDG experience in May/June. • Make this as concrete as possible • Evaluate existing systems (GT3, unicore, legion/avaki, ...) against these requirements on paper in June/July. • Clarify what we want out of this • Based on evaluation - gain real experience with some selected systems during summer • Be more precise on what we will do here • September should the month for intense activity for this group to produce architecture • OGSI tutorial at CERN in 1st week of September. (do this earlier!) • Report/review architecture at EDG project conference end September (Heidelberg) • Architecture document/model delivered to EGEE exec October 15 • Development plan (how to build proposed architecture) elaborated for end of November

10. Work Load Management (WP1) GRAM line protocol changes Likely to be hidden by CondorG Possible use of OGSA mechanisms to publish information Likely to be hidden by WP3 interfaces Description via WSDL/XML messages of Network Server interface Data Management (WP2) Most of the WP2 TB2 components built using Web Service technology, open protocols. Same technology paradigm as OGSA. Migration challenges are ‘only’ of conceptual and architectural but not of technical nature: We deliberately omitted the Service Discovery and Invocation aspect in our services, assuming to use OGSA when it’s available. Network (WP7) Implement low-level monitoring tools will as Web Services Query NetworkCost function as a Web Service Mass Storage (WP5) SE runs as a web service Will support SRM v2.1 as web service Ready to add OGSI layer to make grid service SE control interface suited to grid services SE information interface provided by MDS or R-GMA both of which should become grid services SE data transfer control path suited SE data transfer data path not suited to grids service EDG middleware and OGSA

11. Consumer Factory Application Application Code Consumer Servlet Consumer API Consumer API Registry Consumer Instance Registry API Registry Servlet Producer API Producer Instance Schema API Schema Sensor Producer Factory Schema Servlet Producer API Registry API Sensor Code ProducerServlet R-GMA’s Migration to OGSA WP3 We see OGSA as the future of the Grid and are moving as rapidly as resources permit. • Have started migration to web and grid services • Apache axis • WSDL generated APIs • Providing a wrapper for backwards compatibility