[part of a series of meetings]

Participants

Paul, Tanja, Antje, Karsten, Christian, Jan, Tigran; Al, Dmitry; Gerd

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

Tanja: patches, reviews; looking into NFS; implementing checking of ACLs in NFS server.

Karsten: Debian build machine finished; IPv6 board; trying Gerd maven patch.

Antje: documentation, web-page stuff (please have a look)

Christian: building stuff in ETICS, everything builds, but we don't have src RPMs yet.

Jan: janitor work, SSH v1 doesn't work with pcells (get mapping for an invalid DN) because we're returning an exception; Gerd's maven stuff.

Tigran: NFS server on top of hadoop; need to do pools to do the same ... hunting for a bug: leaking movers and FTP and dcap. leaking connections sockets CLOSE_WAIT similar effect at IN2P3 and PIC (related to firewall issues). LHCb and CMS users (no correlation).

Paul: fed

Dmitry: diverted by enstore / dCache emergencies. Working with Al on HTTP in dCache works. With enstore: the kernel-hang in SL-5 abstract for CHEP submitted.

Al: success in deploying the integrated code. Testing over legacy database. A couple of issues: database is legacy so doesn't have indicies that datanucleus has. What proper place to put the plot images. Can we define non-forbidden subdirectory for ...?

Gene: no thing to report.

Gerd: All week working Gerd's maven stuff: one unit test failing. Won't commit until get an OK from everyone.

Plans for patch-releases

Should we make a new patch release?

Problem getting dCache to run on test instance. Looks like it's fixed; if so, then we start releasing. Currently 1.9.12, 1.9.5, 2.0, ...

Are there any 1.9.13? Yes, there's one.

Which one to recommend? None are green at the moment, which is a problem.

Maybe drop the green?

1.9.12, 1.9.13, 2.0

Releasing is time-consuming work ...

Maybe 9 months is too long. Perhaps 4 months, with one month overlap.

Release for release: OK, but what about customers?

Small changes between releases, so upgrades should be quick.

Green?

Internal DESY dCache.

Gerd: just drop green, other software doesn't have it.

We could document all the problems that we know of it the existing releases. Do the developers know of any problems?

Merges and the merge-queue visible is a big hint: this could generate stats automatically.

We need to discuss this with Patrick.

Trunk activity

Progress with new features...

maven patch

Let Gerd commit it: we have two months to fix it. This could fix things; e.g., Christian EMI spec files.

Gerd: there may be minor things. The issues are work-load change .. very visible once this is committed.

Another issue is that some of the Java dependencies have changed. This might already be an issue with 1.9.12.

The existing ant targets still exist; the RPM dependencies are done via the old ant code. This can be moved, but hasn't happened yet.

We can change this

More complaints early and more time to fix this.

Dmitry: do you have a list of broken gPlazma plugins?

No, they don't fail, but we have no unit tests, so we don't know if they've been broken by the maven change.

You need to change the root of the patch as the source files you modify.

SRM package: move Job from schedule to request packages.

Probably take an hour to fix the patches to the new structure.

There is a maven branch that is ~trunk. Can use this as a test.

Dmitry to try the maven branch and Gerd to commit once Dmitry is happy.

gPlazma loader

Small issue that got fixed, but

gPlazma is plugin based. It has a way of detecting them at run-time.

You put a special XML file

Pretty standard way of doing this.

There is a standard way in Java 6 way of doing this; pretty similar to existing, but it's a standard.

Java uses itself for the Service Provider Interface (SPI).

Drops the XML dependencies from gPlazma.

Repackage packages, to make the different plugins independent maven modules. This separates out the dependencies.

OK.

GUMs

Ted has left, so need to ask Gabriel of current status.

Fermi to look into a gPlazma2 plugin for GUMS.

Web location

While the files are generated on the fly, put them in a temp directory and put billing images in there.

These files are generated every 30 minutes.

In the service httpd batch file where

The skel/share/services/httpd.batch file there's a define context that contains lots of mappings.

set alias plots directory /var/cache/dcache/plots, /var/lib/dcache/

Once this is done: we almost ready to show the patch.

The only bit to add is liquibase support for managing the database.

escaping

Revert the patch and think about it.

Issues from yesterday's Tier-1 meeting

Issues from EMI

Nagios probes are still ongoing.

srmClient and dcap is not in FHS.

Issues from OSG

No issues.

They're moving to the FHS layouts.

Also trying to figure out how to support bestman.

An idea to have a code review of bestman and srmClient; but this fizzled out.

Common problem: jGlobus-2. The current version has bugs that are fixed in jGlobus v2.

Signing policy file formats have changed how they handle email

Parser is refusing to load the policy files.

Tigran: new VOMS server doesn't support email certificates.

Axis v1 problem: that's more a problem with the SRM WSDL that's using old, deprecated format.

Commit/review procedure

Outstanding RT Tickets

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

 RT 6561: dCache 1.9.12-8: WebDav? door with constant CPU activity despite doing nothing

 RT 6671: cleaner: Error in trying to obtain a connection. Retrying in 7000ms

 RT 6688: feature request: collection of files

 RT 6700: FHS and deb packages

Dmitry: working out the procedure for LHCb migration procedure.

Review of RB requests

Yaim

This is heavily used in EMI.

tar RPM, debian

Puppet, Cf-engine, Chef

Find out from Patrick whether we can drop YAIM.

Nobody in OSG is using YAIM.

Meeting one hour.

DTNM

Proposed: same time, next week.