Choose timezone
Your profile timezone:
Powered by Indico
v3.3.5-pre
Attended:
Alessandra , Alessandro DG, Alessandro Paolini, Stephan, Andrew, Dimitrios, Salvatore, Kyle, Oxana, Balazs, Brian
Presentation of Alessandro. He explained the structure of the storage description, taking as an example one included in the Storage Resource Reporting proposal document, another one a prototype version exposed by CERN EOS.
The EOS example is slightly different from the one included in the document. EOS provide a bit more information. The one in the document contains basic information which would be required from the sites.
Julia added that there are couple of possible scenarios, site exposes only file with static topology information, site exposes topology file extended with accounting data, or both. If there is no file extended with accounting data, then site should provide a possibility to query accounting info through some protocol different from SRM
During discussion regarding deployment and whether it would be always possible to rely on storage providers for generation of the required info, Alessandro told , that it was understood that we had a very heterogeneous environment with tens of versions of a particular storage implementation. Therefore , we might not always be able to rely on the storage providers or that storage generates data in the expected format. In particular, when we deal with cloud storage (Amazon). Alessandro pointed that there is always a compromise between simplicity and features. We start with pretty simple approach. Sites are responsible for the storage, they should find a way to generate and expose simple info which is required, probably with custom scripts.
Alessandra told that she would prefer still that required info is generated by the storage itself.
Alessandro mentioned that ATLAS already started the exercise of asking sites to provide the json file with accounting data, and some sites do provide it.
Brian expressed his concern about missing or wrong data and how to deal with validation.
Alessandro told that it is important that data is validated by people who are using it. That this is data which is needed experiments for operations.
Alessandro Paolini asked regarding possibility of using BDII. It is not any more used by OSG.
Julia asked Brian what he thinks regarding deployment on the OSG part of infrastructure.
Brian answered , that it is not so much OSG, rather whether US-ATLAS and US-CMS support it. CMS is slightly different from ATLAS which relies on more traditional storage implementation. Brian could not answer for the whole communities, but thinks it is reasonable. In particular, since CMS is looking forward to have the global view of the CMS topology in CRIC.
Presentation on changes required in GocDB info
Alessandra told that the plan looks fine to her.
Brian asked about split of the CORE and CMS-specific part in CRIC. Julia answered that topology information published by sites is generic, does not have anything experiment-specific and it will belong to CORE CRIC. In fact Brian was rather referring to the accounting data. His concern is that accounting data for operations and management might differ. And it would be required to have separate data flows, one for the experiment operations, which is exposed only in the experiment scope, another one for the management views.
This is a good point which should be taken on board providing the possibility to validate/modify data which is collected according to the proposed plan before exposing it in the management views or accounting reports.