GOCDB/Release4/Development/VSites/VOFeedXML

From EGIWiki
< GOCDB‎ | Release4‎ | Development‎ | VSites
Revision as of 11:36, 22 February 2012 by Jcasson (talk | contribs) (Potential Issues)
Jump to: navigation, search

<< Back to Virtual Sites

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?