WLCG DOMA BDT Meeting

Wednesday 1 Jun 2022, 16:30 → 17:30 Europe/Zurich

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

Topic: WLCG DOMA BDT Meeting

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

1 Hot topics

SAM/ETF tests now use 2048 bit proxy REQ2049284

• smaller key length not accepted by RHEL8 (clones) with default crypto policy

 

2 Token Authorization testbed

Speaker: Francesco Giacomini (INFN CNAF)

3 Tape REST access

Speaker: Cedric Caffy (CERN)

4 Packet marking

Speakers: Marian Babik (CERN), Shawn Mc Kee (University of Michigan (US))

5 AOB

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