VO Feed Example
VO feed for the GOCDB EGI scoped data (ATP will recognize this gocdb data as the 'OPS' VO topology feed).
- If an endpoint is included in a virtual site, a corresponding <service> element must appear in this VO feed as a child of an <atp_site> element corresponding to the parent physical site.
- The VO feed should include all service endpoints, both visible and invisible to EGI.
- For each physical site a <group> element will be used to indicate that all child endpoints belong to the virtual site named by the group
- It is permitted duplicate <atp_site> elements where necessary. e.g. RAL_LCG2 may appear twice with two different sets of endpoints linked to two different virtual sites.
- The feed specifies that all sites are under the ops VO using the <vo>OPS</vo> element.
In summary, the GOCDB to ATP mappings are:
- Site == <atp_site>
- ServiceEndpoint == <service>
- VSite == <group>
The following details about how virtual sites will be monitored is provided by Marian Babik:
- EGI/non-EGI scope is implemented in both regional and central GOCDB - SAM will fetch both scopes from the central GOCDB, which would make it possible to have non-EGI scoped services monitored by the regional SAM (non-egi services won't be distinguished from EGI ones in any way) - central SAM will show only EGI scoped services
- SAM's vo feed concept currently enables creation of arbitrary groups of services that must be already defined in GOCDB (if a group is defined and none of its services are in GOCDB the entire group is rejected, all services/sites listed in the vo feed that are not in GOCDB are automatically rejected)
- Virtual sites can be integrated with SAM via VO feed, which would list all the virtual sites defined in the GOCDB (including all scopes; all such sites and their services would be considered supporting OPS VO)
- With current implementation of ATP at least the following issues can be seen:
- virtual sites containing services outside of given region (no matter what scope) will be shown on the SAM regional instance (e.g. EGI_WMS virtual site would be visible on regional SAM showing only WMSes for that particular region). I'm not sure if this is actually an issue as this might be useful if properly explained in the docs.
- virtual sites (non-egi scoped) containing egi-scoped services will be shown on the SAM central instance
- virtual sites (egi scoped) containing mixture of egi-scoped and non-egi scoped services would be visible correctly on the SAM regional instance (cf. point 1), but on the central instance non-egi scoped services would be cut off from the virtual site (we need to clarify if such use case actually exists)
- In summary, none of those issues are critical, but we will need to discuss them during OTAG to see if there actual use cases behind.
Questions for ATP:
- We've left the infrast="EGEE" attribute on the atp_site element. Is this correct?