Last modified 5 years ago Last modified on 02/21/17 15:32:49

dCache Tier I meeting February 21, 2017

[part of a series of meetings]

Present, IN2P3(), Sara(), Triumf(), BNL(), NDGF(Ulf), PIC(Marc), KIT(Xavier), Fermi(), CERN()


(see box on the other side)

Site reports


Everything is OK at PIC, no issues to report.

Upgrade progress

Today (finally) PIC has migrated to Enstore 6.

The next step is to upgrade dCache to v2.16 on 7th March. The plan is still to upgrade PIC to 3.0 in the near future. Marc has installed dCache v3.0 on the test cluster and it seems to work, but local policy prevents upgrading in too big jumps.

Marc also mentioned that they benchmarked the schema migration(s) needed when migrating from 2.13 to 2.16. This took some 7 hours on their test machine, but they expect the time to be much shorter on their production hardware: it has SSDs and better tuned OS/hardware.

OpenID Connect

Marc opened a support ticket about dCache's OpenID Connect support. This is being handled by Anupam, with some success; however, Marc was missing a nice front-end that would allow users to log in with OpenID Connect.

The particular use-case is for Cosmology experiments. They want to connect using their Google account.

Paul mentioned this is planned, but only after the current QoS work is completed. In the mean time, it should be possible to do everything with a self-written portal.

PIC already has such a portal, so Marc is going to investigate how easy it would be to modifying it as a front-end for dCache.

Problem with REST api

Marc opened a ticket about the REST API


After last week's meeting, NDGF rebooted their zoo-keeper cluster and then rebooted the head nodes. This resulted in the usual set of problems: ~40 pools lost contact with head nodes. This was only fixable by restarting the affected pools.

Gerd will look into this, but he is currently focused on adding systemd support.

Ulf provided some more details: there were no problems after restarting zookeeper. The problems only started after restarting the head nodes.

pool not disable p2p client

Ulf sent an email to support regarding a strange observation. Pools that were declared as disabled as recipients for p2p-transfers were nevertheless still receiving transfers.

Disabling a pool for receiving p2p-transfers seems to work well for ~5 mintues, but then the pool started receiving transfers. Ulf believes this used to work, so could be a regression introduced with 3.0.


Everything is running just fine.

SQL scripts

Paul will remind Tigran


Samuel and Xavier have registered for the workshop.

What's the plan with the programme?

Select HSM interface on the pool

Xavier wants a way to select a specific HSM instance. This is to allow him to verify tape migration from TSM to HPSS.

Paul asked Xavier to open a support ticket, which Paul will point Tigran at.

REST api

Xavier asked if there is any documentation about the new REST API?

Yes, there is a wiki page, which is already somewhat out-of-date:

We anticipate providing better documentation using a standard toolkit for documenting REST APIs.

Support tickets for discussion

[Items are added here automagically]


Same time, next week (with Tigran).