GOCDB/Release4/Development/VSites/VOFeedXML
< GOCDB | Release4 | Development | VSites
Jump to navigation
Jump to search
VO Feed Example
VO feed for the GOCDB EGI scoped data (ATP will recognize this gocdb data as the 'OPS' VO topology feed).
- The GOCDB physical sites are mapped to <atp_site> elements.
- 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.
- 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>
Pseudo-code for building the ATP VO feed XML
Query for all VSites and inner join member SEs. With the result set: foreach VSite { - Create a new in-memory <atp_site> element hashmap: atpSiteElems[key='siteName', value='XML of this <atp_site> element'] foreach VSites->ServiceEndpoint { - Get the hosting physical site name (key = ‘mySiteX’). - Create a new atpSiteElem[‘mySiteX’] map entry (if not already created). + Add a new child <service> element to atpSiteElem[‘mySiteX’] for this SE } foreach atpSiteElem[] { - Add a single child <group> element (VSite name defines the ‘name’ attribute) } - Write all atpSiteElem[] elements to the XML document. - Loop next VSite. }
Important: Using this logic, <atp_site> elements will only ever have a single nested <group> element while <atp_site> elements with the same 'name' attribute are duplicated (which is permitted). However, for any single <atp_site>, this ensures that ALL of the the listed <services> are actually members of both the specified VSite <group> AND the physical <atp_site>, which is correct.
Example
<?xml version="1.0" encoding="ISO-8859-1"?>
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="atp_vo_feed_schema.xsd">
<title>Virtual Sites in GOCDB</title>
<description>Groups of services defined under virtual sites in GOCDB</description>
<feed_responsible name="GOCDB Administrators" dn="/C=UK/O=eScience/OU=CLRC/L=RAL/CN=goc.egi.eu/emailAddress=sct-certificates@stfc.ac.uk"/>
<last_update>2012-02-01T09:46:10Z</last_update>
<vo>OPS</vo>
<!--
note, the name attribute values on group elements are imaginary
as VSites still have to be implemented
-->
<atp_site name="RAL_LCG2" infrast="EGEE">
<service hostname="lcgwms01.gridpp.rl.ac.uk" flavour="WMS" />
<service hostname="lcgwms02.gridpp.rl.ac.uk" flavour="WMS" />
<service hostname="lcgwms03.gridpp.rl.ac.uk" flavour="WMS" />
<group name="All_RAL_LCG2_WMS_INSTANCES_VSITE">
</atp_site>
<atp_site name="RAL_LCG2" infrast="EGEE">
<service hostname="lcgce03.gridpp.rl.ac.uk" flavour="CREAM-CE" />
<service hostname="lcgce07.gridpp.rl.ac.uk" flavour="CREAM-CE" />
<service hostname="lcgce08.gridpp.rl.ac.uk" flavour="CREAM-CE" />
<service hostname="lcgce09.gridpp.rl.ac.uk" flavour="CREAM-CE" />
<service hostname="lcgce05.gridpp.rl.ac.uk" flavour="CREAM-CE" />
<group name="All_RAL_LCG2_CREAM_INSTANCES_VSITE">
</atp_site>
<atp_site name="GRIDOPS-GOCDB" infrast="EGEE">
<service hostname="goc.egi.eu" flavour="egi.GOCDB" />
<group name="OPS_TOOLS_VSITE">
</atp_site>
<atp_site name="GRIDOPS-OPSPORTAL" infrast="EGEE">
<service hostname="operations-portal.egi.eu " flavour="egi.OpsPortal" />
<group name="OPS_TOOLS_VSITE">
</atp_site>
<atp_site name="GRIDOPS-GGUS" infrast="EGEE">
<service hostname="helpdesk.egi.eu" flavour="egi.GGUS" />
<group name="OPS_TOOLS_VSITE">
</atp_site>
</root>
Monitoring Details
The following details about how virtual sites will be monitored is provided by Marian Babik:
Data scoping
- 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
Virtual Sites
- 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)
Questions for ATP:
- We've left the infrast="EGEE" attribute on the atp_site element. Is this correct?
- Please see GOCDB/Release4/Development/VSites#Monitoring_Limitations Monitoring Limitations