wiki:developers-meeting-20160202
Last modified 3 years ago Last modified on 02/02/16 15:20:57

dCache Tier I meeting February 2, 2016

[part of a series of meetings]

Present

dCache.org(Paul), IN2P3(), Sara(), Triumf(), BNL(), NDGF(), PIC(Marc), KIT(Xavier), Fermi(), CERN()

Agenda

(see box on the other side)

Site reports

PIC

Marc reported that they had no problems this week.

He provided an update on the existing, open ticket about a pool hanging. The problem seems to be due to the alarm service being down. They have disabled support in pools for sending alerts and so far the problem has gone away.

Marc mentioned that a similar problem was reported a few weeks ago. This might have the same underlying cause: the alarm server being down. If, after disabling alarms, there are no further problems then this was likely the cause of the earlier problems.

Marc also said that, if dCache.org needs help in testing new code then they can contact Marc through the support ticket.

IPv6

Marc also mentioned that they are trying to get an IPv6-only client to work. There is a problem with the dcap client, in that the version on the dCache web-page is not the latest version.

The latest version on dCache web-page is 2.47.8; within EPEL 2.48.9; and in github is 2.49.10.

PIC compiled the code from github themselves and the latest version seems to fixed the IPv6 problems.

AP/ paul: contact Christian about updating the downloads page.

Paul asked which protocols the IPv6-only client will be using. It will be using dcap, NFS, xrootd and GridFTP, but not HTTP/WebDAV.

Currently this client is for tests, but with the intention it goes into production.

KIT

Xavier reported that everything runs just fine.

Xavier also mentioned that he was at the ATLAS jamborie; he wanted to understand how ATLAS plans to handle staging of file -- then create a replica in their space managed area by copying the file. This seems wasteful as it makes an unnecessary extra copy.

Xavier also mentioned that the syncat dump is something they do every week: dumping the namespace and writing it back into dCache. The process is a single SQL statement that they run once per month, with the problem of finding a machine that is both internal (to have access to the database) and external (to be able to write into dCache).

Pic is also creating the SynCat? entries in a similar fashion; most likely by using the procedure from KIT.

Support tickets for discussion

[Items are added here automagically]

DTNM

Same time, next week.