Last modified 11 years ago Last modified on 06/30/10 18:36:15

[part of a series of meetings]



[see box on the right-hand 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 :)

Patrick: have to provide 1st deliverable for EMI project.

Antje: Thinking about QA. Learning about dCache. Tickets.

Tanja: Tickets, improving pool patch, NFS.

Timur: finished GPlazma class. Followed up on Jan's and Paul's recommendations. Reviewed some other patches. Worked with Tao on monitoring application.

Gerd: away most of the week; on getting rid of last pieces of log4j. Hopefully for 1.9.10 we can have logback.

Thomas: working on Debian packages. New Debian packages awaiting review. Some Yacc-shaving on Chimera packaging.

Tigran: mostly debugging NFS stuff. Little bit of finding bugs.

Jan: ill, some reviews, some webadmin.


Owen: CERN gLite test suites now fully integrated into Hudson. With Patrick's help 1.9.5-19 going into CERN respoitories. Working on dCache-configure mark #2. This now supports Python and BASH modules. Has targets that can include both Python / BASH modules.

Plans for patch-releases

Should we make a new patch release?

1.9.5-20 and 1.9.5-21 will come out this week (or early next week).

Have patched version of 1.9.9 branch (from Timur). If it survives testing then we can release 1.9.9-1.

Also look at releaasing other branches.

Trunk activity

Progress with new features...


Someone needs to write a new login strategy then it can be hooked

Verifying result needed.

Timur to write a patch to implemented validation.


Owen hopes to have external RPM that has dCacheConfigure for 1.9.7 and above.

ActiveMQ stuff

Should dCacheConfigure, by default, be configuring an ActiveMQ? Owen would like to add this in the medium term.

If you want to have a stand-alone ActiveMQ instance then this would be a nice thing to add for dCache Configure.

For embedded ActiveMQ, it's a simple switch.

Perhaps we should change this by default ...

Can we answer support queries about this?

Things to do:

# First of all, we need people who know what this switch does. # Gerd to give a video tutorial on what this does. # Convince someone (in DOT) to deploy this at DESY.

If we don't switch this on then our

We want to have JMS switched on by default for 1.9.10-1

We should switch to using JMS, by default, in trunk.

Gerd upgrades some (not all) pools to latest version of dCache with a new release of dCache.

A goal is to have a release branch "green" after one month of releasing dCache 1.9.x-1 ... subject to NDGF proving that the dCache release is OK.

We push to make a "green" 1.9.8-branch release as a priority.

We intend to 1.9.10 branched at 15th September and released 1st October (subject to day-of-week)

Further releases are every 3 months.

A second golden release ...

Don't want to wait until end of 2011.


  • New gPlazma should work.
  • Configuration system.
  • NFS and WebDAV door.

Support 1.9.5 until start of next run.

January -- April 2011 : release new golden release (1.9.12 probably). This is supported until ~October 2012.

January 2012: new golden release. This is 6-months before machine back on again (if necessary).

Configuration file format


Problem with the automatic configuration management of layout.conf: commenting out a service (in domain) it's difficult to re-enable.

Propose: move over to YAML in the medium-long term.

Would be nice to have a section enabler/disabler property.

Proposed: Default is enabled unless explicitly disabled.

For example:


Making config easier

Database scheme auto-creating.

Also consider switching from PostGreSQL to in-memory database for easy testing.

Support for validating databases

New framework: whatever you have is valid, it can't validate what is there.

Give it an XML file describing the schema; can you use this to verify?

Dmitry has been working on a produce for enstore where schema is converted to XML and the desired schema is also an XML file. The tool creates SQL to move to the new schema.

Would be nice for site-admins to have a tool to check that they're up-to-date.

SRM does auto-migration, but in a custom fashion. Whatever we use, it should be the same for all databases.

The tool Tirgan's looking at does the same kind of thing as what Timur describes. It has understanding the different database SQL dialect.

Owen: we should look at changing pool-manager config to using a lua-like or prolog-like.

Batch files are slowly dying: now mostly used to switch environments as needed.

Long arguments to the batch create commands exists as a temporary step before we ultimately get rid of this.

Some of this is supported via JMX.

One goal is to move all cells to using spring.

Documentation of Hudson and test environment

End-of-July deadline for us to document our QA process. There's currently no documentation for Hudson. Owen, Antje Tigran to work on this.

Merging patches into supported branches

Timur: there is no guarantee that a bug-fix will be accept on stable branch.

For each ticket that should be merged we have to decide.

For each RT ticket, we decide 1) whether we want to fix the problem and 2) if we want to apply the fix to stable branches.

In most cases, the patch to trunk will apply to the stable branches. If this isn't the case then the developer would need some confirmation that their modified patch for the stable branch will be accepted. This confirmation is needed before the developer starts the modified code.

This discussion can take place in the ticket discussion phase of the weekly meeting.

If pool dies after 3 months up-time, people can probably survive; however, if door dies every 10 minutes this probably needs fixing.

developers@… goes to Tigran directly: don't send emails to this email address.

Still mail them to support@… and the request RT-tickets will be reassigned to the merge-req queue.

Issues from yesterday's Tier-1 meeting

Does dcap++ require new release of ROOT?

No, actually not: dcap support in ROOT uses a shared library.

When you use a new ROOT or application is sufficiently non-stupid, then vector read is used and dcap++.

File protocol now works as good as network protocol.

ROOT is now trying to use large reads and sequential reads, which

In Linux, rumour has it that fadvise becomes blocking if you have more than 64-entries outstanding reads (or ..)

Outstanding RT Tickets

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


There are some database tools ... one allows reverse engineering to discover the existing database.

Schema inconsistencies are not impossible. For Chimera it's awkward because there are several upgrade SQL-files. A site may have not have applied all of these files.

We don't have any dCache-specific tool for validating databases right now.

Review of RB requests


Proposed: same time, next week.