Summary from Julia

There is an agreement on an architecture which would consist of the common part representing all WLCG resources (sites and service endpoints as they are described in the sources like GocDB, OIM) and experiment specific configuration extensions implemented in a form of plugins. The basic concept of AGIS : resources provided and resources used - looks relevant to CMS. In order to have a first implementation where common WLCG part (resources provided) is cleanly decoupled from the experiment specific part (resources used) requires refactoring of AGIS code and might take some time. Meanwhile in order to have a prototype which would describe the CMS concepts and configuration , it will be implemented in the existing system, in parallel with the proper implementation described above.

Though it is probably a bit early to define the deployment and support model, this topic was touched, and it looks like the proper model might be similar to SSB, when IT provides a service, while data content is a responsibility of the experiments. Alessandro thinks that CMS involvement in the development and support is desirable, while most of other people rather think that development, maintenance and support should be provided by the central team.

CMS will take final decision regarding usefulness of CRIC for CMS after evaluation of the prototype , which should contain CMS configuration part. The initial timeline for it to happen is 2-3 months from now.

Main contact persons in CMS for this activity are Giuseppe and Stephan. However, in order to implement CMS configuration, WLCG and AGIS experts should understand well the CMS data and work flows, configuration of their main components (services), dependencies between those components , internals of the CMS site/service support models etc... to get an idea how they can be described in terms of data objects. This implies that Alessandro, Julia and Maria would need to have several technical discussions with the CMS experts, and they expect CMS to decide if there are other people in CMS who could be involved in these "tutorials" apart of Giuseppe and Stephan.

The starting point for evaluation and requirement definition is a CRIC prototype: http://cric-dev.cern.ch/agis/ Alessandro ran short demo.

It was agreed , that it would be very useful to have a technical discussion of CRIC/AGIS internals with the main system developer Alexey who is currently at CERN. Giuseppe and Stephan will consider the possibility to come to CERN while Alexey is around.

Julia will create a twiki page to follow the progress of this activity.

Further development plans depend on the outcome of the CMS evaluation. In case of the positive outcome, the discussion of the future of the project will be brought to the WLCG Management Board.

Comments

• From Stephan

We understand that it will take some time to develop the whole system. Our suggestion is to focus on the core, CRIC, part in the first step (and disregard CMS specific configuration needs in this first stage). Seeding the development with parts/copy of the existing ATLAS AGIS system should provide a quick start.

• From Stefano

Julia, it seems to me that some of what you wrote, while a very good summary of what it was said, reflects a bit the ATLAS practice of asking AGIS to know the internals of the other tools so it can produce ready-to-use object. While that is a possible choice, it is only a choice. I will not be surprised if CMS use case results in the requests for simpler objects which do not require an extensive understanding of the CMS tools internals but the CRIC/... developers.

Also it is CMS experience that when it comes to dealing with "information about O(100) things" it is more efficient to retrieve "all data" in one go and manipulate client-side, then have server-side API for each bit.

I am sure this will be more clear once we have started looking at the details of a few examples.

-- JuliaAndreeva - 2016-03-14