The AMI Database Project

1
The AMI Database Project

• Atlas Data Challenge Bookkeeping, and the Tag
  Collector, a new tool for Release Management.
•  

Solveig Albrand,Johann Collot,Jerôme Fulachier
2
First 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)

3
Some 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

4
AMI Architecture
5
The 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.

6
The Indirect Database Connection Mechanism
7
Current 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)

8
Instances of the element object
DatabaseSpecific Objects
Generic Objects
Database Schema Overview
9
(No Transcript)
10
(No Transcript)
11
Future 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)

12
Tag 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

13
Atlas 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)
15
Enforce 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.

16
Tag Collector Architecture
CLIENT
17
(No Transcript)
18
Conclusions

• 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