Choose timezone
Your profile timezone:
Powered by Indico
v3.3.2-pre
Attended:
Andrew, Balazs, Derek, Di Quing, Florido, Stephan, Alessandro, Alessandra, Laurence, Oxana. Federico, Julia
Introduction by Alessandra
We need to simplify the topology info publishing. Why not to reuse approach of OSG for Condor or similar Storage Resource Reporting agreed for storage providers.
Discussion after Derek presentation
Dynamic information is pulled every 5 minutes. The volume is not big, ~4K.
There is no formal description of the provided attributes.
How queues are organized?
Condor does not have queues in a classical meaning of other batch systems. For ARC-Condor configuration , ARC associates queues to a subset of the condor resources.
How VOs fair share and priorities are handled?
A given VO is mapped to several unix users having different priorities.
Laurence mentioned that condor info provider for Glue2 has been developed and already released. CERN is using it to publish to BDII.
Do other sites use it?
Apparently, not yet.
Alessandro asked , how condor publisher handles situation when there are several entry points in front of the same cluster.
There are OSG resource groups which are used to identify subset of resources of the cluster.
Alessandro asked , whether for a particular type of the CPU resources a particular resource group is used.
Not necessary, depends on site admin. Site admin is rather exposing what he expects user to do, rather than strict description of the resource itself.
Then Alessandsro made a point that published attributes which describe in detail a particular type of the CPU resource would not provide reliable information, if the set is not homogeneous. Then it is better to remove such attributes, rather than published misleading info.
Derek told that this is a social problem , if the site admin does not maintain properly the site, very little can be done.
LHCb Dirac does not trust this info, it calculates speed of the CPU on the spot.
Discussion after Balazs' presentation
If we want ARC JSON publisher to get into the latest release we need to agree on the structure during 2-3 coming weeks. Both static and dynamic information can be available the same way.
Discussion after Alessandra's proposal presentation
ATLAS and LHCb do see a value, while CMS does not. CMS records all needed configuration in glidein configuration file communicating with sites via e-mail or GGUS tickets.
In general , the proposal was accepted positively. Balazs was asked, whether he can look in the required structure with corresponding GLUE2 definitions. He agreed.
Discussion after Andrew's presentation
Do we want to publish capacity-related information in GocDB, or rather publish in GocDB the link to JSON which will contain this info? GocDB allows publishing of dynamically created attributes, but not with hierarchy higher that 2 levels. Most of people think that JSON approach is better.
Conclusions
People agreed with the proposal, but more work is required to define the structure and parameters definition.
Balazs will work on the structure. The draft will become available for feedback as soon as ready. In order to try to be inline with ARC schedule, the next meeting is planned in two weeks from now on the 3rd of May.