OU:

- All running well

- Had two xrootd related issues in the last week:

  - xrootd was in a funny state on cstore13, causing that node to fail transfers; not sure why or how;

    xrootd restart on cstore13 fixed that. That happened once before on that node about a year ago ..

  - xrootd hung up on se1, our proxy gateway; that completely halted all WAN xrootd transfers;

    again, xrootd restart on se1 fixed that

- It's possible that the first issue caused a few corrupted log files (adler32 mis-match).

  They were declared lost in rucio.

- Spent remaining hardware funds on more compute nodes and slate node; ETA a few months, of course ...

UTA:

1) UTA_SWT2_UCORE panda queue is now retired in favor of UTA_SWT2_UCORE_RET whose I/O operations use SWT2_CPB_DATADISK

2) We are in the process of retiring UTA_SWT2_DATADISK, additional space was made at SWT2_CPB_DATADISK to accept migrated data, although half of UTA_SWT2's datasets are already in place there.

3) Our Webdav door is in production at SWT2_CPB and ATLAS prefers to use it for I/O despite ATLAS CRIC settings setting gridftp as the higher priority.  This caused somewhat of a problem at startup.  We are noticing a possible problem with the long term stability of xrootd.  Investigating the use xrd.report to generate statistics about metrics within the service.

4) Still working on getting the initial setup of the Kubernetes cluster.

5) Electrical work at SWT2_CPB *SHOULD* not affect operations overnight, but...