Presentation is loading. Please wait.

Presentation is loading. Please wait.

Feedback from the POOL Project User Feedback from the POOL Project Dirk Düllmann, LCG-POOL LCG Application Area Internal Review 20-22 October 2003.

Similar presentations


Presentation on theme: "Feedback from the POOL Project User Feedback from the POOL Project Dirk Düllmann, LCG-POOL LCG Application Area Internal Review 20-22 October 2003."— Presentation transcript:

1 Feedback from the POOL Project User Feedback from the POOL Project Dirk Düllmann, LCG-POOL LCG Application Area Internal Review 20-22 October 2003

2 Feedback from the POOL ProjectD.Duellmann2 SPI Services used by POOL POOL was the first project using SPI servicesPOOL was the first project using SPI services –POOL has actively contributed to the definition of SPI services and LCG policies maintained by SPI POOL is relying on many (almost all) SPI servicesPOOL is relying on many (almost all) SPI services –SCRAM Support –External Software Library –S/W distribution kits and installation scripts –Documentation Tools –CVS repository –Testing Tools –Nightly Builds

3 Feedback from the POOL ProjectD.Duellmann3Savannah POOL relies on Savannah as project portalPOOL relies on Savannah as project portal –Problem reporting and tracking –Support call tracking –Internal task allocation and tracking Experience with problem tracking is positiveExperience with problem tracking is positive –Support call tracking misses some of the functionality (eg cc list, email notification on call assignment to developers) –Some enhancements could even further improve the system Eg automatic escalation after some timeout Insuring that calls have a originator email or name –No real showstoppers found FAQ feature found too simple for larger FAQsFAQ feature found too simple for larger FAQs –(Un)fortunately not our problem yet… Few additions would make Savannah also useful for service projects (in contrast to s/w development)Few additions would make Savannah also useful for service projects (in contrast to s/w development) –Eg Meeting minutes and intervention logs

4 Feedback from the POOL ProjectD.Duellmann4 SCRAM Support SCRAM and LCG ToolBoxSCRAM and LCG ToolBox –Common ToolBox for all projects is essential to insure compatibility across the project –Need to include definition of all supported platforms – including compilation flags which may affect the C++ ABI –Usually quick response to change requests Coverage during the vacation period and toolbox testing before release are essential and are now addressed CVS RepositoryCVS Repository –Works without any problems… NICOS build systemNICOS build system –POOL has been integrated –Not too much benefit so far, but expect this to become important as soon as more platforms are deployed and used in development

5 Feedback from the POOL ProjectD.Duellmann5 Testing Framework Oval has been adopted throughout POOL for integration testingOval has been adopted throughout POOL for integration testing CppUnit used in some areas but pure unit testing harder to apply generally in POOL because of interdependenciesCppUnit used in some areas but pure unit testing harder to apply generally in POOL because of interdependencies So far still rely on specialized python script to fully automate the POOL testing for partial releasesSo far still rely on specialized python script to fully automate the POOL testing for partial releases –POOL has non-trivial dependencies between different test via their data files –Also Data format regression tests impose additional requirement specific to POOL Plan to move to QMtestPlan to move to QMtest –First experience is positive

6 Feedback from the POOL ProjectD.Duellmann6 External Software Library Professional installation and documentation of all available softwareProfessional installation and documentation of all available software Library is getting quite large alreadyLibrary is getting quite large already –Should maybe reflect the difference between build- for-test and build-for-production platforms Eagerly updating all packages on “for test” platforms may generate a lot of effort –Keep a reference count for who has requested/is using a particular package Keeping packages forever without at least a single clear requestor/owner is resource consuming

7 Feedback from the POOL ProjectD.Duellmann7 LCG Software Distribution Useful end user installation scripts for local installationUseful end user installation scripts for local installation –Facilitates development eg on a laptop –Used successfully eg for the Computing School in Karlsruhe Installing all possible dependencies results in 1.5GB installation - some streamlining requiredInstalling all possible dependencies results in 1.5GB installation - some streamlining required –May want to strip server components –May want more customized partial installations Several tar / rpm based formats in preparationSeveral tar / rpm based formats in preparation –Integration with LCG-1 mechanisms required In close collaboration with LCG GD Area

8 Feedback from the POOL ProjectD.Duellmann8 Documentation Tools POOL Reference Documentation is based on doxygen service provided by SPIPOOL Reference Documentation is based on doxygen service provided by SPI –POOL developers just follow the doxygen guidelines defined by SPI –After a release has been tagged the complete documentation shows up “automatically” within a day Positive experience with this SPI servicePositive experience with this SPI service –Only minor problems still to be sorted out Remove test applications from the documentation parsing (duplicate classes and types) ViewCVSViewCVS –Very useful not only for developers but also project admins Use regularly the check-in database to find out what happens inside the larger POOL CVS tree

9 Feedback from the POOL ProjectD.Duellmann9Summary POOL fully relies on many SPI servicesPOOL fully relies on many SPI services –And actively participates in their definition –Service level for POOL is found very adequate POOL has followed the evolution of LCG policies maintained and checked by SPIPOOL has followed the evolution of LCG policies maintained and checked by SPI –Being the first project is sometimes a disadvantage Insuring a consistent/identical build and testing procedure between the LCG AA projects is non-trivialInsuring a consistent/identical build and testing procedure between the LCG AA projects is non-trivial –Because of different project requirements –The task would be simplified by centralizing the task –The load generated by the frequent internal releases in POOL is significant


Download ppt "Feedback from the POOL Project User Feedback from the POOL Project Dirk Düllmann, LCG-POOL LCG Application Area Internal Review 20-22 October 2003."

Similar presentations


Ads by Google