Attending: Dan, Ste, Sam, Jens (chair+mins), JohnH, Matt, Teng, Vip, RobC, Brian, Luke, Winnie Matt and Sam attended (remotely) yesterweek's DPM workshop and presented their impressions and summaries, together achieving near total coverage of the workshop. It *was* a workshop so it took time to discuss things. France and Italy also prominent DPM countries with significant contributions. They've pioneered more the distributed DPM options that we have not yet touched. Which is the hard bit - the storage nodes or the head node? There is a general irisification of bringing astronomers and suchlike onboard, which is good in the sense that more users can improve the sustainability options. Because we must expect upstream support to lessen, partly that they already no longer support non-DOME but it might diminish further. If we need to migrate off DPM, France wanted a five year lead time, but it is not only hard to give guarantees, it is harder still to give anything five years ahead. We can't even be specific about GridPP6. Sam also noted that uncertainty alone can kill a project, however worthy it might be. In terms of supporting DPM branches, there are: - patching - build/package/test - adding minor features - adding major features like a new backend - supporting upgrades of underlying OS (cf. CentOS6->CentOS7). RedHat had rpm, then yum, now dnf, and since DPM doesn't come as container images, it needs to be updated to accommodate the installations on the target OSes (in a word, repackaged.) Previous attempts to understand the code have come a cropper on large refactorings and redevelopments, but it should be more stable now. Also noted Petr put a lot of effort in and has had patches accepted (Czech rep.) In terms of modern devops and containerisation, actual stress testing is hard and problems are sometimes only discovered in production. Italy mentioned the "grid hammer". Needs a clear release cycle and software patch policy. Fx admin-tools were not integrated with DPM build, although Ricardo had done that earlier. Would DMLite shell now replace admin-tools? The purpose of DMLs seems to have changed from time to time, and currently, some functionality requires DOME. Originally, DMLite was meant to be the core framework which could have general databases, backends, protocols, etc. plugged into it. dCache had reduced upstream support problems some years ago for WLCG, but has uptake outside of WLCG and is AFAWK doing OK. Brunel & Lancs have volunteered to pilot DPMs, but this focuses on the install, not the devops. Possibly in order to understand the risks we should make a case for how much (increased) support would be needed to support GridPP DPMs, i.e. RSE effort. Like we usually do with GridPP proposals, it'd need to be reasonably detailed. Brian email that leegacy only supported until september BD Sam https://indico.cern.ch/event/776832/contributions/3378511/attachments/1862155/3060730/StatusDPM2019.pdf https://indico.cern.ch/event/776832/contributions/3378514/attachments/1861982/3060425/dpm_prague_vokac.pdf <-- Petr's Prague talk SS Daniel We should probably get an overview of future plans for all the storage options. to inform future debate. (ceph/hdfs/possix+xrootd, dcache, storm, dpm, eos, but also xcache, arce) I'm a little worried that several options development and support might get downgraded over the next few years. DP Luke Will there be some GridPP support for sites that would like to move to XrootD SE? ok, thx That would be great the HDFS part is just 2 lines in the config L Daniel i have standalone xrootd (read only) on top of possix(lustre) DP Today at 10:52 AM