wiki:developers-meeting-20090811
Last modified 12 years ago Last modified on 08/11/09 18:12:44

dCache Tier I meeting August 11, 2009

[part of a series of meetings]

Present

dCache.org(Patrick,Timur,Gerd,Owen,Paul), IN2P3(), Sara(), Triumf(), BNL(Pedro), NDGF(Gerd), PIC(Gerard), GridKa(), Fermi(Timur), CERN(Andreas)

Apologies

FZK, Sara, IN2P3

Agenda

(see box on the other side)

Site reports

BNL

  • Phenix experiment *needs* the dcap client for Solaris - what's the status of this request?

Owen reported that he has been delayed.

PIC

Nothing to report; things are running well.

NDGF

Gerd reported they had an issue where he doesn't yet have all the details. It seems that there was some interruption of database connectivity between Chimera and the PostGreSQL database; however, details are, at this time, sketchy.

Gerd also reported that their new hardware has arrived. They will soon start migrating services over to this new hardware.

(Andreas?) asked whether Chimera run as a daemon or is it a library? Gerd said it was both: from dCache's point-of-view, Chimera is a library for talking to a database; however, there is also a daemon process that may be run that allows mounting of the namespace via NFS.

CERN

Andreas reported that there has been sites in Russia reporting a problem when upgrading to dCache SRM client. This was due to the requirement on Java v6.

Fermi

Timur was relaying a query from OSG. They were are asking about the latest release of v1.9.2 which has a bug where gPlazma no longer works. This problem is due to the package containing two JAR files.

Sara

(via email)

We don't have any issues.

IN2P3

(via email)

No issues.

Coordinating upgrades

Patrick reported that the Management Board as asked Patrick / dCache.org to help coordinate sites' upgrading. Could sites review their plans for the next few months about when upgrades are planned and report this information to Patrick? This would allow us to present this information to the LCG Management Board and to coordinating who is available from dCache.org at those times.

The plan for dCache.org is to allow sites to upgraded to the Golden Release (1.9.5) ready for when LHC goes online. This release is planned for the end of September, which we appreciate is rather late.

ACLs and PNFS

Do ACLs work with PNFS? Yes ... except for inheritance. A directory ACE (part of a file's or directory's ACL) may specify that freshly created files or directories should inherit this ACE. Chimera supports this but PNFS doesn't.

ACLs on files may be necessary to allow the ATLAS use-case of allowing production users to delete all files.

Upgrading to 1.9.5

Is this a synchronised upgrade?

All head-nodes must be upgraded at the same time. Current indication is that v1.9.4 pools should be compatible with v1.9.5 head-nodes, but that head-nodes must be upgrade to 1.9.5 before pools are upgraded to 1.9.5.

Head-nodes with 1.9.5 should be compatible with pools < v1.9.4 with some caveats (e.g., how the migration module is used).

Plan to have v1.9.5-1 released at end of September. This is to allow sites to upgrade in October; i.e., after a period of running in their pre-production sites.

Splitting up BNL

Pedro reported a very speculative idea: splitting BNL into two dCache instances. One would always run the latest version of dCache (so gaining experience with that version) whilst the other would be a few dCache versions behind. The split would be based on space tokens. The "newer" dCache instance would run Chimera, populated either by copying data or by going through a migration process.

One issue with this is how to provide a unified service for end-users. Ideally, end users should not be aware that there are actually two dCache instances. Pedro felt confidence that ATLAS DQ2 would be capable of doing this for WAN traffic but he was concerned that end-users using dcap would have problems.

There was a discussion on how a unified dcap service could be provided without the end-users being aware of the two dCache instances. There was no strong conclusions beyond that testing was required.

DTNM

Proposed: same time, next week.