Virtual sites are a mechanism to arbitrarily group existing service endpoints together e.g. into an NGI grouping. The service endpoints themselves will still belong to their parent (non-virtual/physical) sites. This feature has originally been requested at https://rt.egi.eu/rt/Ticket/Display.html?id=987.
Virtual Site Entity
A virtual site is a new GOCDB entity containing the following information:
- Contact E-Mail
- Monitored flag (Y/N)
- Child service endpoints
- Roles held over the virtual site
A single service endpoint may belong to many parent VSites and a VSite may have many child service endpoints. The existing cardinality between (non-virtual) sites and service endpoints remains: a service endpoint may only have one parent (non-virtual) site.
Virtual sites will not appear in any existing PI queries. To expose virtual site information we will introduce two new PI queries:
- vsitename - Only return info for a specific virtual site
- scope - Only return virtual sites that are (In)visible to EGI
Example Output: XML
- vsitename - Only return info for a specific virtual site
- dn - Limit results to user with given certificate DN
- scope - Only return virtual site roles that are (In)visible to EGI
Example output: XML
When a user creates a virtual site they will be granted the role "Virtual Site Administrator" over the site. Other users will be able to request a "Virtual Site Administrator" role over the virtual site and the administrator will be able to accept or reject these requests as they see fit using the standard role management mechanism.
Any user can create a virtual site. When adding service endpoints to the site we will show a message saying: "Before adding service endpoints to this virtual site please ensure you have permission from the affected service endpoint administrators". We recommend this is defined as a formal procedure for creating a virtual site. The premise is that a user creating a virtual site can easily be held accountable for their actions. As highlighted below, a role granted over a virtual site does NOT give any permission over child service endpoints (the VSite only acts as a way of grouping existing SEs).
In order to modify the virtual site such as adding/removing endpoints, a user needs the Virtual Site Administrator role over the virtual site.
The following changes will be made to support virtual sites in the user interface:
- New link: "Add Virtual Site" added to the left hand menu bar
- New link: "View Virtual Sites" added to the left hand menu bar
- When viewing a virtual site the properties listed in "Virtual Site Entity" above will be shown
- My Sites will show virtual sites administered by the current user
- A virtual site cannot have a child service endpoint that doesn't already have a parent site.
- A role granted over a virtual site does NOT give any permission over child service endpoints.
VO Feed for ATP
In order for ATP to use virtual sites, GOCDB have been asked to produce a VO feed for the GOCDB EGI scoped data (ATP will recognize this gocdb data as the 'OPS' VO topology feed). This feed should not be used by anyone except ATP and won't be supported outside of ATP's use (other VOs will not be supported). If there is a requirement for VO integration in GOCDB, it would need to be considered separately in a new proposal outside of VSites.
A sample of the XML we will produce is available here.
- Background information about VO feeds: https://tomtools.cern.ch/confluence/display/SAM/ATP+VO+Feeds
- Sample ATP feeds for different VO topologies:
- ms_topology: http://dashb-cms-vo-feed.cern.ch/dashboard/request.py/cmssitemapbdii
- atlas_topology: http://atlas-agis-api.cern.ch/request/atp/xml
- lhcb_topology: http://lhcb-web-dirac.cern.ch/topology/lhcb_topology.xml
- superbvo.org_topology: http://bbr-serv09.cr.cnaf.infn.it:8080/nagiosvo/superb-sites-for-nagios.xml
- alice_topology: http://sam-alice.cern.ch/alice_topology.xml
- ops_topology: example
The proposed VO feed ATP solution (above) for monitoring virtual sites presents the following limitations:
(With input from Marian Babik)
- With current implementation of ATP at least the following issues can be seen:
- VSites grouping services outside of a given region (no matter what scope) will be shown on the regional SAM instance (e.g. ATP <group> elements named after an 'EGI_WMS' VSite would be visible on regional SAM showing only WMSes for that particular region - we assume the regional SAM only recognizes those <atp_site> elements named after the physical sites in this particular region). I'm not sure if this is actually an issue as this might be useful if properly explained in the docs.
- VSites(non-egi scoped) that group egi-scoped services will be shown on the SAM central instance (unless only egi-scoped VSites are queried for).
- VSites(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.
- Will this design work for the other operational tools?
- With this implementation, can VSites be monitored?
- With this implementation, can VSites appear in the dashboard?
- Will this work for the ATP folks? Are we expected to provide a VO feed of VSites to ATP? If so what VO name(s) would we populate the feed with? (GOCDB doesn’t store VO information)
- Can all operational tools address the use cases detailed in https://wiki.egi.eu/wiki/Logical-site with our proposal?
- Do other tools need a mechanism to distinguish which virtual sites should have availability reports calculated (similar to the monitoring flag)?
- Do the other ops tools require any other flags to distinguish one type of virtual site from another?