wiki:developers-meeting-20100706
Last modified 11 years ago Last modified on 07/06/10 17:38:53

dCache Tier I meeting July 6, 2010

[part of a series of meetings]

Present

dCache.org(), IN2P3(), Sara(), Triumf(Simon), BNL(), NDGF(), PIC(Gerard), GridKa(), Fermi(), CERN()

Agenda

(see box on the other side)

Site reports

PIC

Gerard reported that, in production, everything is OK.

On Wednesday, they're planning on upgrading PIC to 1.9.5-21.

Gerard also reported that he's planning on splitting off the Tier-2. Currently, the PIC Tier-2 is embedded within the Tier-1. The motivation is that PIC can migrate to a more recent branch of dCache, to give end-users access to the more advanced features that are available in the newer versions (such as NFS) and to provide the Tier-1 experience at running newer versions of dCache, ahead of deploying them within the Tier-1 instance.

The plan is to play with the splitting-off process for the next 2--3 months. This process will involve moving some 300 TB of data and a pnfs-to-Chimera migration.

If all goes according to plan, the splitting off will take place in October.

Gerard asked which version he should use?

We have just released 1.9.9-1. This is a normal short-lived feature release. Starting with 1.9.9, these short-lived releases will be supported for 9 months; previous releases were supported for 6 months. 1.9.9-series will be supported until 1st April 2011.

We plan to release 1.9.10-1 about the same time that time. This release will be supported until July 2011; however, PIC wouldn't be able to test their splitting-off process with a 1.9.10 release.

Also salient is that we are planning on making another golden release: 1.9.12. This is to allow people to receive long-lived support for a version of dCache that has WebDAV, NFS 4.1, etc. We plan to release 1.9.12 "Spring 2011" (1st April).

So one option would be to use a "short lived" feature branch initially (1.9.8 or 1.9.9, for example) and, later on, migrate to 1.9.12 for the "golden" support.

Having just release 1.9.9-1, we are now working on releasing 1.9.8-2. We will mark 1.9.8-2 as "green". With 1.9.6-series no longer supported, we would recommend people upgrade to 1.9.8.

We may make another bug-release for the 1.9.7-series (1.9.7-3), but we're unlikely to mark this release "green". This is because there is only 3 months left of support for the 1.9.7 branch, so we would recommend people upgrade to the latest 1.9.8- or 1.9.9-series release instead.

In August, DESY will upgrade one of their production instances to either 1.9.8- or 1.9.9-series.

Triumf

In production we are OK.

Simon reported that, on one of their pool nodes a RAID-6 system suffered two disks failed at the same time (!). They are now using dCache migration to move files away from this node. This activity is moving some 7 TB of data to other pools.

Does migration module do checksum?

In fact, the migration module uses the same pool-to-pool transfer mechanism as all other dCache transfer activity. Whether a pool-to-pool transfer triggers a checksum configuration is determined by the configuration of the destination pool. If that pool has "On-write check enabled" then migrated data will be checked.

Simon also asked if there is any progress with ticket RT-5696 (describing how gPlazma didn't seem to work with an SCAS instance).

Paul: sorry for the delay, we'll chase this one up.

Support tickets for discussion

[Items are added here automagically]

DTNM

Same time, next week.