1. Persistency Project (POOL) Status and Work Plan Proposal
Dirk Düllmann
PEB Meeting, July 16th 2002

2. Persistency Project Timeline
Started officially 19 April
Initially staffed with 1.6 FTE
Zhen Xie/CMS (100%) - MySQL scalability and reliability test
DD (60%) – Completed discussion about requirement list and deployment plans with experiments
Persistency Workshop 5-6 June at CERN
More requirement and implementation discussions
Draft work package breakdown and release sequence proposed
Additional experiment resource commitments received
Since beginning of July
Real design discussions in work package started
active participation now ~5FTE
Daily meetings with core component WPs
Meet twice a week for Catalog WP
Collection and Meta Data discussion just starting now
Project h/w and s/w infrastructure being defined and becoming available

3. Experiment Deployment Plans
Summary of first round of discussions with the experiments
Numbers referring to minimal requirements for a first release (rather than to constraints imposed by the design/implementation)
Timescale for first release – September (CMS)
Others are interested but more relaxed about date
Volume – TB (CMS)
Files – several 100k (ALICE)
Distribution – O(10) sites (CMS)
Number of population jobs – 10k (CMS)
Use of REFs per Event (CMS/ATLAS/LHCb)
LHCb: O(100) refs per event; CMS ( );
ALICE: not relying on Refs so far
Recovery from jobs failures (CMS, ATLAS)
CMS: Existing setup allows to just re-issue same job
Append to existing files
LHCb: each file is written by exactly one job
ALICE: single event spans several files

4. Experiment Focus of Interest (prioritised by # of votes)
RootIO integration with grid aware catalog (ALL)
Transparent Navigation (ATLAS/CMS/LHCb)
ALICE: maybe, but only in some places
EDG (ALL), Alien (ALICE), Magda (ATLAS)
MySQL as RDBMS implementation until first release (ALL)
Consistency between streaming data and meta-data (CMS/ATLAS)
At application defined checkpoints during a job
Early separation of persistent and transient dictionary (ATLAS/LHCb)
Initial release supports persistency for non-TObjects (ATLAS/LHCb)
without changes to user class definitions
Support for shallow (catalog-only) data copies (CMS)
formerly known as cloned Federations
Support for deep (extracted part-of-object hierarchy) copies (CMS)

5. Practical Project Organisation
Stay close to initial RTAG component model
Work Packages are (nearly) completely aligned
Constraint:
at least two significant contributions (>30% FTE) per work package to insure independent work
have core component developers co-located at CERN
Some interface/design discussion will need to take place
inside co-located work packages outside CERN
by / phone meetings
small workshops at CERN

6. Proposed Work Package Split
Earlier Drafts have been shown on the Persistency Workshop and also later by Torre
Catalog and Grid Integration
Zhen Xie (50%), Maria Girone (50%), Mathias Steinecke
Storage Manager & Refs
Markus Frank (50%), Giacomo Govi (50%), Fons Rademakers
Dictionary & Conversion Services
Craig Tull, Stefan Roiser (50%), Victor Perevoztchikov (30%)
Collections and Meta Data
David Malon(30%), Chris Laine (50%), Julius Hrivnac (20%), Sasha Vaniachine (20%), RD Schaffer(30%)
Common services, integration and testing
Giacomo Govi (50%), Maria Girone (50%), Zhen Xie (50%)
some commitment made by experiments still under discussion

7. File Catalog – First Results
Scalability and performance for native MySQL catalog close to completion
no big surprises compared to Persistency Workshop reports
nearly flat scaling up to 200 clients from 10 nodes
ms per catalog update (depending on client load)
impact of batching several updates in one transactions
Some instabilities observed
database had to be recreate after schema corruption
server lockup after file system full condition
Need to understand both in more detail before any larger scale production deployment

8. Catalog Scaling Results (M. Girone/Z. Xie)

9. EDG/Globus Integration
Close contact with EDG WP2 about Giggle (EDG/Globus Replica Location Service)
Need to understand software integration with EDG provided middleware
software dependencies, release cycle, supported platforms
POOL will assume standard EDG testbed installation for client and server machines
Plan to repeat catalog scalability and reliability tests with Giggle as backend
currently some issues since EDG software is not yet released for RedHat 7.2

10. Basic S/W Infrastructure Setup
Persistency is the first LCG project
will need to operate before some of the basic LCG services are fully agreed
Need to participate during setup basic s/w infrastructure
Repository directory structure
Need to build on a few basic services
Error Reporting and Exception hierarchy
UUID generation
Component loading and configuration
Configuration control, build and automated test system
For now start as pragmatic (and simple) as possible
Extract implementation for all of the above from existing projects
Expect to change as soon as wider scale agreement is achieved in LCG
will require additional work for re-factoring eg after V0.0.1 release

11. Work Package Progress Core Components – StorageMgr
Draft header files and UML diagrams are circulated
Gaudi Introspection has been made independent from GAUDI
Received example code implementing persistency for foreign (non-TObject) classes
Expect to conclude first round of interface discussions this week
start with implementation of component prototypes
Collections & Meta Data
Design discussions between people involved have started but are still in an early state
Aim for first interface proposals during the next two weeks

12. POOL Hardware Resources
Discussed hardware requirements with other groups in IT
Proposal distributed by Bernd Panzer
Now-December
2 disk server machines to be setup as catalog servers
one with native MySQL catalog / meta data server
one installed as EDG testbed node acting as replica location server
10 client nodes for concurrency test
installed as testbed nodes once EDG for RH7.2 is available
September-December
stability and distribution test (decoupled from development setup)
2 additional disk servers for decoupled stability and distribution tests
3 disk servers for ROOT data
November-December
more resources for experiment framework integration tests from experiment data challenge allocations as required by experiments

13. Proposed Release Strategy
AIM
complete first internal release cycle as soon as possible
Start by integration of core components
StorageMgr, FileCatalog, Reflection, CacheMgr & Refs
result transparent navigational store operational
Other (more external) components will start design and implementation already
but will only be integrated in later releases
in particular Collections and MetaData are essential for final product but less tightly coupled
Only the first external release will have all components integrated
usable for expert users (eg no automatic installation)

14. Proposed Release Sequence
R Basic Navigation
all core components for navigation exist and interoperate
StorageMgr, Refs & CacheMgr, Dictionary (r/o), FileCatalog
some remaining simplifications
Assume TObject on read/write – simplified conversion
R – Collections
first collection implementation integrated
support implicit and explicit collections on either RDBMS or RootIO
persistency for foreign classes working
persistency for non-TObject classes without need for user code instrumentation
EDG/Globus FileCatalog integrated
R – Meta Data & Query (external)
meta data annotation and query added
for event, event collection and file based meta data

15. Summary Real development work has (just) started
more than half of the people who signed up for the project are actively working towards a very first release
Consultancy and (in some areas) modifications from ROOT team
expect some inefficiencies because of vacations and project being a test case for new LCG s/w components and procedures
September release date and list of requested features seem incompatible
Need to limit the influx of new requirements and feature request
Propose to aim rather for relevant release content than a too aggressive release date
Propose to reschedule V0.0.3 Release for November
Assuming that committed resources become available

16. Root Storage Manager Alternatives
User objects are kept in a Root tree
Root trees are typed (as eg RDBMS tables)
trees need to created by SM
objects need to be placed in the right tree
are optimised for sequential access
should allow foreign (non-TObject) persistency
User objects are kept as keyed Objects
could allow more efficient random access
but some scalability issues
all keys are read if a directory is opened?
could probably be fixed
Do keyed foreign objects work already?
if not could they be made work?
CMS is actively prototyping second approach for their COBRA Root prototype
POOL project will concentrate on first approach and re-synchronise after first development release

17. Storage Manager
Several half day brainstorming sessions with Markus Frank last week
cache manager interface and implementation issues
role of context
integration with dictionary and conversion
token structure for Root/RDBMS tables
basic model file-container-object
container maybe a Root tree, a Root directory, a RDBMS table
in more detail
flow of control inside SM during read, write, commit operations
first UML diagrams have been circulated