110 likes | 125 Views
WP6 Testbeds and Services. GridPP Middleware Workshop 4 th -5 th March 2004 Steve Traylen. Outline. Testbed History Application Testbed Development Testbed WP6 Services E.g., CVS, AutoBuild LCFG Installation of Middleware Support. Early Testbed History.
E N D
WP6 Testbedsand Services GridPP Middleware Workshop4th-5th March 2004 Steve Traylen
Outline • Testbed History • Application Testbed • Development Testbed • WP6 Services • E.g., CVS, AutoBuild • LCFG Installation of Middleware • Support
Early Testbed History • In 2000 it was all based on an RPM distribution of Globus – Testbed 0 (McNab). • These were still used through testbed 1. • Later LCFG arrived and this allowed a release to be completely specified. • Software and configuration could be modified which was critical for an incremental distributed development cycle.
Testbed History • After release 1.1.4 the release cycle did not change much which is good. • The testbed could cope with many, even multiple upgrades within a day. Important for typos.
Application Testbed • About 22 sites in 8 countries. • 6 of these sites are in the UK. • Currently South, London and North grid all represented within EDG. (Scot has been.) • The UK maintained many core services such as R-GMA registry and RLS servers. • In fact EDG in the UK would survive without the rest of Europe.
Development Testbed • UK has maintained a core site within the development process. • Essential as an early learning ground for the new software. • A presence within development of EGEE and LCG now continues.
WP6 Services. • The UK not directly involved but this is a big influence on middleware development. • CVS. • A central CVS repository was always very sensible. • Bugzilla worked very well. • A good way to contact developers and prioritise but not forget requests and bugs. • 2800 bugs, 87% resolved.
Autobuild • Took longer than ideal to mature. • The build queue was missing for ages. • Developers learning automake/autoconf took some time. • In the end it proved very valuable. • At times this created what appeared to be a huge bottle neck – but only because it was the final stage. • This technology now continues into LCG/EGEE. • Suggestions • Try and use community projects that are mature from day one.
LCFG Installation of Nodes • Auto configuration was essential to developing in a distributed deployment. • Avoided some trivial configuration errors. • However now it is almost a requirement to use LCFG for any EDG software. • Suggestion. • Configuration of middleware needs scrutiny earlier. This is the API the sysadmin or configuration system has to work with after all.
Support • In the UK the tb-support@jiscmail.ac.uk worked and continues to work well. • Used by sysadmins and UK grid users. • The UK having people very involved with EDG development was ideal for this. • LCFG hides the inner workings of configuration. • Better documentation and short cookbooks required for sysadmins and end users to avoid the need for this.
Conclusions • The UK was always active with in the application and development testbeds of EDG. • This puts many sites in an excellent position to join LCG in coming months. • Many UK members were involved with integration process, loose cannons , developers, sysadmins… • EDG currently comes as a huge bundle. • This is good for fast development but does not match reality of resources.