Title: The AMI Database Project
1The AMI Database Project
- Atlas Data Challenge Bookkeeping, and the Tag
Collector, a new tool for Release Management. - Â
Solveig Albrand,Johann Collot,Jerôme Fulachier
2First Steps
- The AMI project started in the spring of 2000.
The first realization was an electronic notebook
for Atlas LAr testbeam runs. - Soon, we had other requests for other database
projects - ? Needed to reuse software, and to make
databases self describing so they can be used
in a generic way. - The AMI web site is at
- http//larbookkeeping.in2p3.fr/AMI
- (has a PDF version of this presentation)
3Some Design Principles
- Use an RDBMS.
- Use many RDBMS.
- Be generic.
- Distribute geographically
- Manage long term projects (schema evolution)
- Place emphasis on user interfaces.
- ? SQL and Java were chosen
4AMI Architecture
5The Deployment of AMI on Several Servers.
- Connections pass through a router database.
- This enables selection of the correct server,
jdbc driver, and database for access to the data. - The databases contain their own
description.(Entities, relations, and meta
information and behaviour.
6The Indirect Database Connection Mechanism
7Current Status
- Used by 6 projects.
- In particular for the Atlas Data Challenge 1, for
the Application Meta Data alias Production
Bookkeeping. (gt 50 000 files)(Physics ? logical
file name) Does not deal with physical locations
or replication. Atlas uses Magda for this
function. - Available interfaces Java, Command line, Web,
(C prototype)
8Instances of the element object
DatabaseSpecific Objects
Generic Objects
Database Schema Overview
9(No Transcript)
10(No Transcript)
11Future Plans for AMI/ Atlas Bookkeeping
- Replication at several sites. (Atlas DB group)
- Build tools to manage AMI databases.
- Introduce WEB SERVICES
- GRID Integration, certificate authorisation
(Spitfire) - Communication with MAGDA (talk tomorrow Wensheng
Deng) - Build application specific tools especially for
Atlas Bookkeeping.(Production Managers, more
features for physicists)
12Tag Collector
- A database based application for release
management. - AMI compliant (but uses PHP).
- Sits on top of CVS, and CMT (our configuration
management tool) - In use since September 2001.
- Some History
13Atlas Release Approaches Anarchy!
I goofed with the tag for the External/GaudiInterf
ace package for release 2.0.1. It won't affect
the SRT release, but it will affect attempts to
build the CMT release. I had forgotten (and I
suspect I won't be the last one to do this) that
CMT has a very formal response when the major
version ID increases (I changed from 01-02-07 to
02-00-00). It takes it to mean that the new
version is incompatible with the earlier one, and
that packages that depend upon this package will
essentially break. At the very least they should
change their dependency on this package from
something like use GaudiInterface-01-
External to use GaudiInterface-02-
External I mindlessly chose 02-00-00 without
thinking about this implication. In order to be
backwards compatible I have created a new tag
for External/GaudiInterface
GaudiInterface-01-03-00 The code is identical to
that of 02-00-00. But this version of the
package should be used for any CMT release build,
be it 2.0.1, 2.0.2 or 2.1.0. Sorry about that.
Sigh... David
OK, I've moved Reconstruction-01-03-01 on
egammaRec-00-00-03 and on Reconstruction /ChangeL
og. Sorry about that David On Thu, 18 Jan 2001
091302 -0500 (EST) "S. Rajagopalan"
ltsrinir_at_bnl.govgt wrote gt gt gt Hi - The tag for
egammaRec should be egammaRec-00-00-03, not
"02". gt Please pick up the correct tags for this
release. Thanks. srini gt gt On Thu, 18 Jan
2001, David Rousseau wrote gt gt Hello Maya gt gt
Please include Reconstruction-01-03-01 in the
release (details below) gt gt Cheers gt gt David gt gt
egammaRec-00-00-02 gt gt - add
_load and _entries files gt gt - update to
CBNT ntuple
Dear All, Many thanks to those of you who
responded to the mail about missing tags. There
are still some problems - mainly incomplete
tags. Such accidents are inevitable if the same
2-3 people tag most of the packages for
practically every release and if one person
(myself) has to collect and sort out a large
number of (sometimes incomplete or conflicting)
tags. This has to stop.
14(No Transcript)
15Enforce some control!
- Forbid anarchic tagging. (which packages are
tagged, and when, respect the hierarchy) - Reduce developer error. Tag selection and CMT
requirements files. - Make release building more efficient.
- Centralize information on packages, especially
documentation.
16Tag Collector Architecture
CLIENT
17(No Transcript)
18Conclusions
- Tag Collector is a victim of its own success.
- Will be rewritten using AMI base classes.
- Made more modular.
- More features.
- To look at the Tag Collector go to
- http//larbookkeeping.in2p3.fr/athena
- Username demo, no password