Last modified 11 years ago Last modified on 01/18/10 14:33:59

[part of a series of meetings]


Tigran, Tanja, Owen, Paul, Jan; Gerd; Dmitry, Timur, Vijay


[see box to the side]


Up to two minutes (uninterrupted) per person where they can answer two questions:

  • What I did last week (since the last meeting),
  • What I plan to do in the next week.

No questions until we get through everyone :)


This week: Chasing up RT tickets, fixing WedDAV listing; Next week: Pool Manager adaptor


Last week: Help DESY migrating; emergency release of fixes. Next week: small fixes here and there


Last week: dcap for autools and ETICS, new certs, Next week: training in using ETICS,


Last week: This week:


Last week: get information about networking in dCache, web-admin tool work This week: try to reproduce problems reported about Serialisation


Last week: working on upgrade of public dCache sytem


Last week: srmls requests, submitted a patch.


Last week: testing script that fails because enstore fails if passed a Chimera ID instead of PNFS ID. Running through the regression test-suite, some still failing.

Running in a different mode, getting file information trash directory rather than PnfsManager

ETA: end-of-week alpha version of compatible enstore with Chimera, ready for PIC to test.


Last week: Busy with upgrade dCache to 1.9.6. Moving to Jetty SRM. One compatibility issue with ARC: this is an old issue but is now worse: buffer overflow in ARC software. Fixing small items from TODO list. This week: continue fixing items from TODO list.

DESY Chimera migration

Some information:

The pnfsDump was undertaken on two machines concurrently. This is to prevent a machine-crash from preventing migration. On machine machine it took some 28 hours, on the other machine it took 48 hours. The difference almost exclusively due to different times spent accessing data from database.

The injection took some 10 hours.

PostGreSQL 8.4.2

The database storage on the new Chimera namespace uses FibreChannel? connected NetApp? storage.

Status of work for 1.9.5

A (quick?) review of activity needed for the 1.9.5 release

Tigran: tested current HEAD; passes all tests. Would like to fix:

the "no write pools available/configured" message the Chimera start-up script.

Plan to do a release of 1.9.5 Friday.

Owen can reproduce Chimera problem with SL 53.

Diagnostics about start-up isn't as good as it should be: Gerd's patch wasn't sufficient to get the problem logged.

To reproduce the problem, throw an Exception from a cell's constructor.

Status of work for 1.9.6

A (quick?) review of activity needed for the 1.9.6 release

Tigran: testing this now. Another dead-lock found by Gerd (see RB: #1386), which would be nice to include.

Plan to release 1.9.6-2 this Friday.

Patch has gone in that moves Transfer Manager and Pin Manager to utilityDomain so 1.9.6 is now releasable.

Status of work for Trunk (a.k.a future 1.9.7)

A (quick?) review of activity needed for the 1.9.7 release

Owen: would like to discuss how we get version numbers from SVN.

Probably don't want to couple the version number with SVN: if we move to Hg or git then we get hash number instead of a release.

After this is sorted, would like to do a dcap release.

Is there any plans to "standardise" the communication with Mattias ?.

Next step is to pull dcap out of dCache source tree; to make it a stand-alone project in SVN.

Entry for packages into next Ubuntu is previously February, so it might make it into the next Ubuntu long-term support release.

Update on replacement SVN disk

We are perminately running out of space on What we'll get is NFS disk with backups. When moving there's always possibility for issues, like permissions.

We should choose

Gerd: just pick a date.

If releases are this Friday then upgrade over w/e. Otherwise send email.

SVN 1.5 database format can track branches, making managing branches a lot easier.

Issues from yesterday's Tier-1 meeting


Issue with too many requests causing Tomcat to

Can dcache startup script update the ulimit to some value? Nope. It would be nice to add a call to ulimit.

Outstanding RT Tickets

[This is an auto-generated item. Don't add items here directly]

RT 5168: Design flaw in how AL and RP is propagated

Start to fail requests if space-manager is disabled. Check with Jon whether this will break anything.

RT 5325: BerkleyDB metadata repository import does not make files cached in volatile pool

An issue that was discovered whilst fixing the bug was that, with LSF=volatile, a file should always become cached and not sticky.

If no copies on the pool then the name-space entry is removed.

A/L=online then file is marked sticky. This seems to be a bug.

Should be in the pool selection that these pools are not selected for A/L online.

There t_StorageType can be "volatile" in SRM, that matches these semantics.

Add agenda for future meeting.

RT 5396: non-privileged user for dCache

In 1.9.5 SRM cannot run as non-root user as it needs mounted PNFS.

Another error because the class-path is too long.

File and databases access issues aside, only the NFS server will need to run with root privs. Actually portmap


Give ticket to Tigran.

Also ...

Gerd's tickets

Gerd opened two tickets about SRM. Could Timur have a look at them?

  1. table being dropped.
  2. illegal state transition.

First one will be dealt with in Dmitry's ongoing work in the SRM-ls patch.

Review of RB requests


Proposed: same time, next week.