Last modified 12 years ago Last modified on 02/06/09 17:46:52

dCache developers video meeting

Participants : Fermi(Dmitry,Gene,Ted-initially,Vladimir,Timur), NDGF(Gerd), Desy(Irina,Paul,Tatjana,Tigran)


  • VOMS-gPlazma and the 1.9.2 branch,
  • The review process: RT and RB,
  • Making 1.9.1 the recommended version,
  • SRM review process,
  • Releasing 1.9.3 and the future of trunk- & 1.9- branch.

VOMS-gPlazma and the 1.9.2 branch

Ted has provided a set of patches that he anticipates will fix the observed regressions.

The question of moving towards using a single auth. record within dCache arose. It transpires that there is an anticipation that future version of gPlazma will likely return a different auth.record from the one(s) it currently returns. There is no plan for when this will happen.

Whilst there was general agreement that having a single auth.record is desirable, Tigran's work on effecting this was based on gPlazma's current auth.record (UserAuthBase). Given the anticipated new auth.record, changing dCache code to use only UserAuthBase may not be optimal. Also, there was general agreement that the teams priority currently doesn't lie in fixing inconsistencies in the space manager and removing legacy code: other problems have a higher priority. Because of this, Tigran agreed not to work further on unifying dCache's auth.record usage.

Ted also mentioned work on VOMS validation: verifying that the extended attributes signed by a VOMS server are valid. There are two modes: a existing/legacy mode that requires gPlazma to trust the VOMS server's certificate and a full-chain mode where only the top-level CA certificate is needed [provided the intermediate certificates are available, I guess]

The review process: RT and RB

Timur asked which system is to be used and what the benefits are of RB over RT. Which one should we be using?

Tigran & Gerd described a number of benefits. These included:

  • in-patch comments,
  • much better display of diffs:
    • side-by-side view of changes,
    • per-character highlighting of what has changed
    • optionally expanding the collapsed (missing) parts of a file between change-hunks.
  • displaying diffs against diffs,
  • remembering against which SVN version a patch applied (no loss of ability to review due to HEAD moving on),
  • ability to select a subsets of people to review code,
  • an automatic tool for uploading code as a diff.

It is believed that all users are registered in RB, so RT and RB are equivalent systems.

It was agreed that we continue to trail RB for a week then make a decision whether to use it.

1.9.1 as recommended release

Agreement that we should make a 1.9.1-5 release that includes Ted's fixes. Given the amount of testing this release has received (e.g., Jon using the pools), it was agreed to make this new release the recommended version.

Review of SRM code

Timur announced that he is inviting people to contribute towards this review process. The reviewers are external so no one can contribute directly. Because of this, he's investigating how people can contribute.

Gene also added that things are still fluid with the mechanics of the review process; how people can contribute currently isn't clear. Also fluid is the scope of the review.

1.9.3 release and branches

There are still some outstanding changes between 1.9-branch and trunk. These need to be consolidated.

Once trunk and 1.9-branch are the same, the 1.9 branch is dropped (removed from SVN?). Trunk then becomes an always-releasable branch. NFS-4.1 and ACLs will be merged into trunk and the 1.9.3 branch will be cut.

FTP list command

Gerd reported that the new FTP list commands are not functioning with GUI clients. Firefox and Nautilus (iirc) were tried and neither worked. Since the format is being changed, it would be nice to allow GUI clients.

Tigran pointed out that there's currently no requirement that we support GUI clients; also, are we sure which ls command the clients are using?

Agreed plan is that Gerd to investigate further and report back developer's list.


There was a discussion between Gerd and Timur about how the pin manager and migration module should interact when files are moved or copied. The conclusion was to leave the migration module's behavour and for pin manager to attempt to move the pin. Should it fail (for whatever reason) it reports this failure back to migration module, allowing it to retry.


Same time, next week.