[part of a series of meetings]

Participants

Agenda

[see box on the right-hand side]

Postcards

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 :)

Plans for patch-releases

Should we make a new patch release?

Trunk activity

Progress with new features...

Workshops

Lund

First: workshop in Lund; make sure you have hotels and flights booked.

dCache developers

Need someone to take care that there's an agenda, etc .. a caretaker.

Dmitry has volunteered to take on this role.

Patrick will give Dmitry access to the agenda page so he is free to change the slots.

Topics include: review gPlazma; plan for the next year.

Important to work out the planning what sessions we shall have.

Patrick to send Dmitry the list of participants.

Tanja to find a nice restaurant: preferably one light one and a more heavy one, too.

emails and mailing lists

Two questions about NFS .. no answers yet.

Do I need to restart dCache after changing

If you change the exports file then you must restart dCache server.

Are you sure it's NFS v4? Yes. Ah, that's a surprise.

What about uid / gid mapping on the client host.

You must run the nfsidmapd daemon.

With Unix-permissions, the linux kernel checks if the ID string contains only digits. If so, then it treats the string as a UID / GID.

Working on integrating Kerberos support

I run only NFSv4 or NFSv3 but not both. Can this be fixed?

Yes; the problem is that they are started as separate services. The both try to open the same port-number, so cannot work. There is support for running both within the same cell, but this is awkward to make the choice between NFS-3, NFS-41 or NFS-3+NFS-41 with Spring.

This is for a demo of NFSv4.1/pNFS at Fermi.

The current behaviour is that the NFS server prevents clients from staging file. This is a deliberate policy decision, but hard-coded.

NFS has a time-out of 30 seconds: if hard-mounted then client will hang until file is available; if soft-mounted then the client will keep retrying.

Patrick: if portmapper is running then dCache doesn't work with NFS.

Needs a configuration in /etc/sysconf/rpcbind to tell it that dCache is allowed to register with port number > 1024.

Are you happy to do exercises with Scientific Linux 6?

Yes, that should be OK.

The SL-5 builds is something Tigran supports; Today, learnt that Fedora-core 16 kernels support NFS 4.1 out-of-the-box. Installing the FC-16 kernel in SL-6 then NFSv4.1/pNFS should just work.

Issues from yesterday's Tier-1 meeting

News about enstore / pnfs problem seems to be solved with a kernel upgrade.

ON client running the kernel 2.6.18-2.38.5.1. Cat on the name of file (via a dot-command). Since encp (a lot of stuff) is "monitoring" '(nameof)' and similar monitoring.

The file ID has changed.

The funny thing was all reads were sent back were OK; none returned stale-file-handle.

Infinite loop on open on the file didn't crash the kernel.

The encp crashes the kernel almost straight away.

encp does open on '.(nameof)('

Could be the file-size doesn't match the size of the file.

We can either match the kernel-patch to our code or we say "it's solved".

Pragmatically, we can point anyone with the problem to the newer kernel version.

Issues from EMI

Nothing really to reported, except the metrics.

Metrics

EMI produces metrics: SLOC count, FindBugs?, etc.

Tigran pointed out the code-branch that is srmclient-only.

Patrick suggested they take it as one component: client+server. Take the SLOC-count of both.

Do they have exclude filters? Probably; what for? For a specific error; e.g., "your java name isn't compliant" (e.g., from PMD or FindBugs?). We exclude stupid cases (e.g., due to auto-generated).

Some things like taking Thread.start out of cells would take a lot of effort, so we won't change it. It's too dangerous to change it only to decrease the FindBug? counts.

Do they run FindBugs? on other projects? Yup.

Tigran wants to drop FindBugs? from our source-tree.

Outstanding RT Tickets

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

 RT 6167: bringonline failed due to pinning failed:finding read pool failed

Gerd added to the agenda.

Patch to fix this problem has been committed to 1.9.5 branch (and all others, too).

Do we want to do a release of 1.9.5 to get the fix out? Tigran: yes.

Ticket #6218

Yesterday Dmitry says it works with v1.9.5, so if 1.9.5 uses the same jline version as dCache v1.9.10 then it's our bug and needs to be fixed.

If the problem is in jline then we can patch it and submit the patch upstream.

If not, then we can fix our code ;-)

Tigran will try not to forget about it.

Review of RB requests

Please (Paul) look at the GSS code (it's for 1.9.12 ;-)

DTNM

Same time, next week.