wiki:developers-meeting-20101201
Last modified 10 years ago Last modified on 12/01/10 18:53:23

[part of a series of meetings]

Participants

Tanja, Antje, Karsten, Paul, Owen, Christian, Tigran; Dmitry

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

Christian: work bug attributes mapping (state and priority). Going through the guidelines.

Owen: EMI work; srm-client now deployed and tested against dCache. Testing against CASTOR and DPM (maybe storm?) are todo. Slight conference on EMI (all-hands etc). Patch for dCache configure.

Paul: ..

Tanja: working on user-forum archive; NFS, cleaning up data server side. Tickets.

Karsten: finished Argus plugin patch; now submitted to RB. Looking into planning the next AH meeting-- not looking too good for conference meeting rooms.

Antje: documentation .. updated install chapter now online ; tickets.

Gerd: Perd Lunquist (Swegrid) hopefully (join us next week). Working on background checksum checking in the pool. Catching up on small bug-fixes. Spending time with IN2P3 debugging their setup. Debugging Java 64-bit on Solaris.

Dmitry: outline sent of how to make SRM scalable. Analysing the code shows one problem is the job state is stored in multiple tables. This could be fixed. Studying the SRM over SSL patch. Looking at Chimera integration with enstore -- added triggers from Tigran. There are some minor issues. When restoring the file, hsm is being set to "osm". It isn't clear where this is happening.

CMS want the multiple SRM front-end support in 1.9.5, so do the minimum changes to achieve this.

New golden release? No, Jon likes the stability of 1.9.5 so will continue with this for 2011.

Next fall (autumn) to migrate to Chimera.

Tigran: committing threadless movers code (nearly done). Second phase to tidy up. Fighting various broken systems. DESY has upgraded their CMS instance to 1.9.10-4, which uncovered some bugs.

Plans for patch-releases

Should we make a new patch release?

Pool startup fix is needed: waitForFile doesn't work in 1.9.10. It looks like we broke this at some point.

CMS doesn't have a space manager. Do they need to start one? Specifying the "access latency" and "retention policy" through SRM won't work. You also would get a lot of errors.

dash/bash?

Trunk activity

Progress with new features...

Should we add a command to the /opt/d-cache/bin/dcache script: version dCache, version Java, thread dumps, copy of log files, etc into a tar file?

Looking at sites, see interesting error messages.

Logback: could we set up a central logging facility that sites can send messages. Logback centralised logger.

We could have something like that for DESY dCache instances.

Tigran to try to collate everything at DESY together.

Paul to ask Tier-1s about this.

Issues from yesterday's Tier-1 meeting

Looks like a use-case for quotas

Fermi CMS has a quota system.

Implementation of space-tokens on read would solve the problem .. but do we want to solve this problem in this way?

Issues from EMI

unit tests

Certified or not?

Suggest: we reject patches until they come with a unit-test.

For the unit-tests it's very easy to run via "ant test".

We currently have no "ant func-test". This would be useful.

The point of func-test is to allow people to easily add tests.

Comment in unit-test links back to the bug report (RT).

Guidelines

Going through all the guidelines to identify where we

QA

R4C

Who generates the metrics? ETICS.

Do we have a procedure to measure our compliance with EMI?

Yes. We can discover this. Christian to update Trac pages with this information.

Christian to add links in Trac to point to the current version of all guides and QA documents.

Is there guidelines for submitting tickets? Yes, there should be.

PTB (Project Technical Board) has the last say on the "severity".

Java for EMI

Two problems: "immediate" and "in future".

Doing the nightly build of a component (dCache, UNICORE, gLite, ARC) share a common environment. They want to standardise the build environment. Server-build requires Sun-JDK.

Two options:

  • EMI could change default from OpenJDK to SunJDK. Justifications are needed to support this option.
  • Separate branch for EMI.

Problem is with Batiks: this doesn't work with OpenJDK.

Should we be forced to fix this? Shouldn't they fix their build system.

Tigran: if we get money to fix this then we do; otherwise EMI have to fix their build system.

Do we support OpenJDK?

Need Patrick to know how EMI-funded people are responsible for.

Minimum version of Java

Gerd: Java JDK have had lots of bugs over time. I see sites running old versions.

Could we introduce a minimum version 1.6.0_18 maybe?

If you have a down-time, this could be a problem.

We should do this on trunk only for new release.

Should be mentioned in the release notes.

Gerd to update the script.

Outstanding RT Tickets

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

RT 5973: dCache 1.9.5: support for /etc/grid-security/vomsdir/<vo>/*.lsc instead of lcg-vomsdir RPM?

A couple of tickets about pool-to-pool; Gerd, could you have a look at them?

Gerd to look at the pin-manager.

Review of RB requests

DTNM

Proposed: same time, next week.