WLCG DOMA BDT Meeting

Europe/Zurich
Brian Paul Bockelman (University of Wisconsin Madison (US)), Maria Arsuaga Rios (CERN), Petr Vokac (Czech Technical University in Prague (CZ))
Description

Topic: WLCG DOMA BDT Meeting

Videoconference
WLCG DOMA BDT Meeting
Zoom Meeting ID
69074333781
Host
Petr Vokac
Useful links
Join via phone
Zoom URL

TAPE REST API v1

  • found ambiguities in the specification while implementing gfal/FTS support
    • restart discussion with storage developers
    • there are implicit assumption in current specification
    • make documentation more clear / add details that were never said explicitly, but with whom everybody most probably agree
  • next gfal2 2.21 release comes with TAPE REST v1
  • next FTS release comes out also soon, but that one doesn't yet implement TAPE REST functionality
    • this will come later
    • still withing few months
  • FNAL is preparing deployment of new dCache branch with TAPE REST
    • dteam VO will be used for test
    • should become available by next BDT meeting

Packet marking

  • last week meeting with dCache developers
    • running flowd service will be automatically discovered / used by dCache
    • development necessary on dCache side
      • especially marking start of transfer (end of transfer can be hooked to existing accounting functionality)
      • coordination with WLCG monitoring requirement (similar information is needed)
    • brief discussion about HTTP-TPC extension for packet marking
      • agreement on this proposal
    • it should be clarified if this may be backported in golden release
      • production sites usually hesitate some time before changing major version
  • WLCG Packet Marking WG meeting next week Tuesday, June 7, 18:00
There are minutes attached to this event. Show them.
    • 16:30 16:35
      Hot topics 5m

      SAM/ETF tests now use 2048 bit proxy REQ2049284

       

    • 16:35 16:50
      Token Authorization testbed 15m
      Speaker: Francesco Giacomini (INFN CNAF)
    • 16:50 17:05
      Tape REST access 15m
      Speaker: Cedric Caffy (CERN)
    • 17:05 17:20
      Packet marking 15m
      Speakers: Marian Babik (CERN), Shawn Mc Kee (University of Michigan (US))
    • 17:20 17:30
      AOB 10m

      Dualstack storage and client happy eyeballs support

      • sites still "disable" IPv6 by not binding service to IPv6 while keeping AAAA records in DNS
      • clients prefers IPv6 and waits for timeout before fallback to IPv4
        • this timeout can be too long so fallback mechanism doesn't work
        • addressed decade ago by happy eyeball fast fallback defined in RFC6555 / RFC8305
          • enabled by default in curl that comes with RHEL8 (curl 7.59.0)
          • used by XRootD HTTP-TPC on RHEL8
          • used by any DPM (can cause troubles LCGDM-2961 with by default enabled IP-based security)
      • should our transfer clients deal better with these kind of connectivity issues?
        • davix (gfal2 / FTS) comes with alternative libcurl 7.69.0 backend
        • enabled by environment variable DAVIX_USE_LIBCURL=1

      Status of non-adler32 checksum support in gfal2?

      • Does gfal2 send Want-Digest during file upload?
        • no, this is not used
      • e.g. transfer with MD5 checksum fails with dCache destination
        • truncate -s 1M /tmp/1M
        • gfal-copy -f --checksum-mode=both --checksum md5:b6d81b360a5672d80c27430f39153e2c file:///tmp/1M davs://se1.farm.particle.cz/dpm/farm.particle.cz/home/atlas/atlasscratchdisk/SAM/x
        • this transfer fails
      • dCache store MD5 only if upload comes with corresponding Want-Digest, e.g.
        • curl -v --capath /etc/grid-security/certificates -X PUT -L -H 'Want-Digest: md5' -H 'Authorization: Bearer secret' --upload-file /tmp/1M https://se1.farm.particle.cz/dpm/farm.particle.cz/home/atlas/atlasscratchdisk/SAM/x
        • this transfer succeeds and MD5 is also stored with file metadata
      • dCache doesn't generally support non-default checksum
        • default is configured per-pool (filesystem) using csm set checksumtype
        • only some protocols (e.g. WebDAV, GridFTP) support additional checksum type per transfer
        • impossible(?) to specify alternative checksum type for xroot protocol