wiki:developers-meeting-20090610
Last modified 12 years ago Last modified on 06/10/09 15:38:09

Participants

Agenda

(see Table of Contents)

Status of 1.9.3 release

Current patches that are blocking a release:

Patch 288

Cells: Make sure all threads are interrupted on cell termination.

Results in regression: leaking threads

Patch 290

PnfsManager: Don't sleep on setFileMetaData in case of error

dCap release

Tigran wanted to discuss this.

Issues from Tier-1 support meeting

There were some issues raised at yesterday's Tier-1 support meeting.

Killing HSM transfers after pool dies

If a pool dies (e.g., OutOfMemoryException) and HSM transfers have been requested, these will continue resulting in the file being staged. This staging of files confuses the pool. Doris asked (half expecting the answer "no") if we could cancel the requests.

Should we look at extending the HSM interface? Should we have a separate directory for files to be staged into, so the dir that the pool uses is completely under the pool's control?

Fix for SRM / space-manager issue

Gerard was asking.

Info service bug(s)

Paul has started following this up.

Jon's PNFS usage data O(100 GiB)

Paul thinks he would like the data, anyone else.

Inconsistencies between files- and db- billing

Timur said he would work on this.

Switching off files billing?

Just an idea.

Break-even parameter

Do we need to do anything here? Some options are to provide better documentation of the parameter; provide recommendations on how to introduce in a new pool into dCache (each site seems to have their own procedure) ...

Issues from pre-GDB meeting

The Pre-GDB included a session on dCache, including a presentation by Brian Davies on dCache - T2 feedback. The presentation echoed feedback from sites: misleading-, confused- or old- information reflects sites state of knowledge.

Documentation, documentation, documentation

dCache book was described as "obsolete" and wiki as non-educational; how do we fix this?

Having a FRF

During the meeting Gerd suggested having a Frequently Requested Features (like a FAQ). This would be a (simple) wiki page with copy of all requested features, no commitment to implement anything, no prioritisation.

Have a trouble-shooting guide

We always start out checking the same things. Can we document these somehow?

A patch or new feature?

The patch #266 (when looking up a file's metadata, don't do unnecessary level-2 reads) may speed up access using dCache. Do we wish to have this in Trunk only, or also in the 1.9.0, 1.9.1 and 1.9.2 branches?

Open tickets

Review of outstanding review requests

DTNM

"Same time, next week"

2009-06-10 16:30 (CEST)