Attended: Alessandra, Andrew, Bruce Becker, Greg, Vincent, Maarten, Baptiste Grenier (EGI), Alexey, Gavin, Julia
Several things proposed in Alessandra's slides to be added to the structure:
GPU, MPI, OS
resourcetype - possible values like batch, cloud, etc...
The structure should be flexible to be able to be complemented with new attributes as needed
Baptiste asked why not to try to generate the file from BDII/GLUE info.
This is possible to do so, Laurence already tried for CERN. Though we would like to have a simple structure, which contains only minimum of information required for job submission and accounting.
Site people who gave a try to describe their resources are in favour of a single file per site rather than a single file per CE.
Though there could be advantages to have it generated by CE.
Looks like we should give people an opportunity to select whether they would like to produce one file per site or to allow CEs to generate a single file per CE. In both cases all necessary info should be contained in the published files and should be consistent.
Andrew asked what happens if CE goes down, while CRR is published on the site level and CE is part of CRR. Julia told that we were discussion just static info, no dynamic info like status or number of running jobs were foreseen to be addressed in CRR. Status of the CE should be checked by the SAM tests and recorded in the monitoring tools.
Depending on the site size and complexity, the CRR site file can be either created manually (for small sites with simple configuration) or be generated out of configuration files for big and complex sites.
Andrew reminded that we should attach units to the name for numeric attributes to avoid ambiguity.
Queue is not a generic enough term , may be we should replace it with something else, like share or set. Suggestions are welcome.
Whether VO should be a property of the resource, queue, or CE? Need a bit more thinking. In the discussion after the meeting, came up with the proposal to have VO attribute at the resource level (which might cover most of the use cases), though allow to overload it on the queue/ce level.
Would be useful to describe not just batch resources, but also resources like Vcycle, to see whether the structure is good enough to do so. Andrew will do it for Manchester. Gavin told that CERN would also give a try.
Overall conclusion is that we need a hierarchical structure built around resource concept.
Julia will work on a new structure taking into account feedback of Alessandra's presentation, files generated by pioneer sites and the ATLAS proposed structure from Alexey (attached to the agenda), put it in the googledoc and let people know, so that they could comment. We re-iterate and then will ask pioneer sites to give another try with a new structure.
Next meeting will take place after sites are ready to comment on their experience with the modified structure. Most probably beginning of the next year.