Name: WLCG DOMA BDT Meeting
Start: 2022-06-01T16:30:00+02:00
End: 2022-06-01T17:30:00+02:00
Location: No location set

Hide

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
  
  smaller key length not accepted by RHEL8 (clones) with default crypto policy
- 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