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.

I have read and understood the above.

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.

agreement that we do not release the P010 immediately but way for possible fix in CtrlRDBAccess

A proposal for "amnesty" on Jira issues discussed at JCOP CB; no agreement to close old cases without reviewing it first; the issues will be reviewed and acted upon, with the aim of closing them if possible; initial set of issues under review already

CAEN component and OPC UA Server:

discrepancies between OPC UA and DA namespaces; partially reviewed with the help of experiments; 80% cross-checked.

Migration panel (from OPC-DA to OPC-UA) practically ready; pending on stabilization of OPC-UA Server namespace. The reason for the delay in delivery of the panel is because of the OPC-UA namespace instabilities.

OPC-UA server for Linux is considered as stable and being used in production in ATLAS

No urgency to prepare a Windows build. Timescales for CMS and ALICE are the beginning of LS2

Questions/Discussion

modification of DPType - would we loose archive? Not if we ADD an element to DPT, without removing the old one (ie. without leaving the gap); if one removes something from the middle of definition, this may be lost at the project export-import (ie. ATLAS way of upgrades)

Is the ASCII backup a mandatory step? Should be optional as some people do regular ASCII exports anyway, and this will save time

Mapping of multiple subscriptions to multiple OPC groups. Text in the radiobox is misleading; improve/clarify

What is the procedure for rollback? A simple ASCII import

Should we have access control in the operational panels? Convention was not to put it on the fw panels... to be reconsidered

Important limitation: in CAEN Easy, if you add a board in the middle of a crate, you need to re-create all the DPs... Should be reviewed as a part of consolidation.

Mapping of OPC groups to subscriptions was done for large systems in the past; for the event-driven readout, this is not relevant anymore. In ATLAS experience, this mapping is not needed for newer crates or newer firmwares. And it is much simpler to configure. Performance tests done by ATLAS

Which driver number should we use for CAEN OPC-UA? The panel should propose by default the same driver number as CURRENTLY USED by OPC-DA address. For this we give up on the use case to import only one crate to UA, and keep the other in DA as not really needed. The OPCUA client configuration panel should also be pre-filled with some standard information, such as localhost and port numbers

Having multiple clients connected to a single server seems to be faster that connecting to a single one (this seems to be for OPC-DA). In CMS they keep a few crates on the default driver num 6, and then move other crates to higher driver numbers for others. This seems to give better performance in CMS. Is it the same for OPC-U? In ATLAS' OPC-UA experience, this seems not to be the case, yet no systematic testing was done. To be tested.

Do we have a "keepalive" for monitoring the crates/boards with new OPC-UA? Yes, the CAEN internal keepalive and its timeout are exposed now to OPC-UA. How about a safe read-write "dummy register" for a complete roundtrip? Ideas to have monitoring of the crate but also individual boards (sometimes mainframe is OK, but a board is dead). Fan speeds are commonly used as of now by many people to check the aliveness.

Clarification: in the scope of the VENUS project a new tool was prepared to extract the information about the CAEN crate (layout of boards, firmwares) and dump it to a file; it would also dump the OPC items to give us information. This needs to be run per mainframe and could be run in parallel to OPC. ALICE is already using it. It is a C program -> candidate for a 5 min talk next FWWG.

AOB:

Next meeting to be scheduled in 4 weeks: XPra (Marc B. BE-ICS), SupervisorD logging (Giovanna Lehman, EP-DT); no meeting in 2 weeks as many people may be away.