The LHCb Conditions Database on the GRID


The idea behind this Twiki page is to discuss the issues about how the LHCb jobs will use the CondDB when run on the LCG. For the moment, this page is just a list of specific questions/answers. When the topic will be clearer, the page will hopefully follow wink

The CondDB on the GRID: Q & A

Do we assume that we will be using the CondDB with ORACLE backend on all the Tier1 ?

Philippe: We were assured all Tier-1's will run an Oracle service

Are there other possibilities, e.g. MySQL backend or XML slices ?

Philippe: Oracle should be OK for (re-)reconstruction. For analysis, the use case for the CondDB is less clear to me, but I would assume generally there is no such need unless users want to e.g. refit tracks, and even then probably the DST would contain enough information. If willing to use a re-aligned detector, a reprocessing would be necessary at a Tier-1. For simulation however, we should consider using also the CondDB (e.g. to access the geometry and get rid of the (in)famous XMLDDDB). For this type of usage however, my suggestion would be to use e.g. an SQLite slice of the CondDB, as one know a-priori which "date"/tag to use.

Nico: At the Tier-1 level, SQLite may be considered as a "backup" in case something goes wrong with Oracle. We can also imagine to have some XML files available in case the COOL distribution (i.e. the implementation of the CondDB by the LCG team) has some problems. But in both cases (SQLite and XML), this will be emergency situations where the jobs will provide their own data files.

What are exactly the items to be provided by the LHCb Configuration Service ? Should we define generic ORACLE user account for the read-only access to be used by everybody ?

Philippe: Oracle end-points should be given in the CS. Read-only access should (provided this doesn't open a Pandora box with security people) be done using a generic user/password. Who cares if someone else reads our CondDB. Of course, it should not be apparent in the code otherwise CVS sniffers would ban us wink

Nico: The CS should provide a list of relevant Oracle end-points. Database name, schema name and user name will not change from one site to another and will probably be "hardcoded" in the job's configuration file. I don't know about the passwords. Maybe we won't need it if we can use Grid Certificate instead.

Do you forsee jobs that are updating the information in the CondDB ? How ORACLE access rights for these jobs are to be handled ?

Nico: we don't forsee jobs updating the CondDB. Actually, the only "editable" CondDB will be the Master Copy (at Tier-0) and it should not be possible to edit it through the GRID. As a consequence, all GRID users will have exactly the same priviledges to access the CondDB, which should simplify the connection procedure.

How Tier2 jobs will access the CondDB ? How Tier2 centers should be attributed to their respective Tier1 centers ?

Philippe: If access is needed from other than Tier-1's, I would suggest either remote access (what is the performance penalty?) or SQLite slicing. It should only be for analysis then.

Nico: As Philippe says, jobs on Tier-2 (Monte Carlo production and User Analysis) will know the time period and the version of the CondDB they need. They can thus provide their SQLite slices.

What happens if a particular CondDB instance is not available ?

Philippe: I think we should use redundancy, i.e. for a given site there is a list of CondDBs in descending priority. Of course jobs may be penalised. If the shortage lasts long or is anticipated, one could disable the availability of the CondDB for that site. As the subject of this threads suggests, we would like probably to use the FC in order to flag the presence of the CondDB with a given tag at a particular site (e.g. one LFN per tag and replicas declared when the tag is made available). It would be good to be able in the FC to "disable" an SE, be it for real data access or for DB access (in order to cope with SE stoppages at the level of the WMS).

Nico: Just to add a bit of information: the default procedure of the CondDB access seems to be: if the given Tier-1 doesn't respond, go to Tier-0. It appears also that the new implementation of the CondDB will be able to do this chosing procedure automaticaly. It just needs a list of database server to try to connect to.

-- NicolasGilardi - 16 Jan 2006

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2013-03-20 - IllyaShapoval
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback