In order to enable an iCal export link, your account needs to have an API key created. This key enables other applications to access data from within Indico even when you are neither using nor logged into the Indico system yourself with the link provided. Once created, you can manage your key at any time by going to 'My Profile' and looking under the tab entitled 'HTTP API'. Further information about HTTP API keys can be found in the Indico documentation.
Additionally to having an API key associated with your account, exporting private event information requires the usage of a persistent signature. This enables API URLs which do not expire after a few minutes so while the setting is active, anyone in possession of the link provided can access the information. Due to this, it is extremely important that you keep these links private and for your use only. If you think someone else may have acquired access to a link using this key in the future, you must immediately create a new key pair on the 'My Profile' page under the 'HTTP API' and update the iCalendar links afterwards.
Permanent link for public information only:
Permanent link for all public and protected information:
Several blockers on XRoot + EOS side, fixes are in the pipeline. Julien will follow up at tomorrow's x-section meeting.
HTTP+TPC: we should be able to test transfers with CNAF, in both directions, using delegated X.509 credentials.
In parallel, Julien will continue with configuring and testing token authorisation. This is not a blocker for the LHCb migration.
LHCb DAQ tests to EOS have started but they are experiencing some issues. They are throttling at 1.5 GB/s per machine, whereas they should be seeing throughput of 10 GB/s. Maria is debugging this with Chris and the networking team. It makes sense for us to wait until these are resolved before we run any tests on our side.
Getting PUBLIC into Production
(From IT/SME meeting) AMS are keen to resume testing as they are blocked by the 1m file limit. It seems that the filename structure they use is hard-coded in many of their scripts and would take some time to fix. Those are really two separate issues (the CTA migration and the problems created by having too many files in a directory). This should be followed up in x-section meeting.
CAST errors seem to be caused by retries on their side of files which have not yet made it to tape. As the files have the same filename, the retry is failing. Julien is following up, see INC2684046.
Repack of r_public_user: 150 tapes to go.
CTA Status Update
Cedric will deploy 3.2-1, then 4.0-1.
Reclaiming a tape will empty the recycle bin and remove the IS_FROM_CASTOR flag so that it can be added to a supply pool. Files cannot be recovered from the tape after it has been reclaimed.
Next, Cedric will investigate issue #930 CTA Frontend crashes after removal of repack request with 15000 files
There are minutes attached to this event.
Thank you everyone for your efforts in the CAST migration!
Ongoing Tests (Vova)
AMS: have hit 1m file limit in CASTOR. To be followed up at SME meeting.
NA61/SHINE: EOS team are assisting with setting up storage at their DAQ. Luca will contact them to set up a meeting. Follow-up at SME meeting and x-section meeting tomorrow.
DUNE: They have a CTA test endpoint but haven't started testing yet. At one point they said they wanted to migrate to CTA in February but there is no rush, they will do a data challenge in 3Q2021. See #213