Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

GOCDB/Release4/Development/VSites

From EGIWiki
Jump to navigation Jump to search

<< Back to GOCDB/Documentation_Index
<< Back to GOCDB/Release4/Development

Virtual Sites

Introduction

Virtual sites are a mechanism to arbitrarily group service endpoints together. The service endpoints themselves will still belong to (non-virtual) sites. This feature has originally been requested at https://rt.egi.eu/rt/Ticket/Display.html?id=987.

Cardinality

A service endpoint may belong to many virtual sites and a virtual site 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.

Vsites.png

Virtual Site Entity

A virtual site is a new GOCDB entity containing the following information:

  • Name
  • Description
  • Contact E-Mail
  • Monitored flag (Y/N)
  • Child service endpoints
  • Roles held over the virtual site

PI Queries

We will introduce two new PI queries containing virtual site information:

get_virtual_sites

Parameters:

  • vsitename - Only return info for a specific virtual site
  • scope - Only return virtual sites that are (In)visible to EGI

Template:Hidden

Example Output:

<?xml version="1.0"?>
<RESULTS>
   <VIRTUAL_SITE PRIMARY_KEY="157G0">
 	<NAME>ALL_OPS_TOOLS</NAME>
 	<DESCRIPTION>All central instances of the EGI operational tools</DESCRIPTION>
 	<EMAIL>John.Casson@stfc.ac.uk</EMAIL>
 	<MONITORED>Y</MONITORED>
 	<GOCDB_PORTAL_URL>https://gocdb4.esc.rl.ac.uk/portal/index.php?Page_Type=View_Object&object_id=21960&grid_id=0</GOCDB_PORTAL_URL>
 	<SERVICE_ENDPOINT>				
 		<HOSTNAME>goc.egi.eu</HOSTNAME>	<GOCDB_PORTAL_URL>https://gocdb4.esc.rl.ac.uk/portal /index.php?Page_Type=View_Object&object_id=21956&grid_id=0</GOCDB_PORTAL_URL>
 		<SERVICE_TYPE>egi.GOCDB</SERVICE_TYPE>
 		<HOST_IP>130.246.143.160</HOST_IP>
 		<IN_PRODUCTION>Y</IN_PRODUCTION>
 		<NODE_MONITORED>Y</NODE_MONITORED>
 		<GOCDB_PORTAL_URL>https://gocdb4.esc.rl.ac.uk/portal/index.php?Page_Type=View_Object&object_id=21960&grid_id=0</GOCDB_PORTAL_URL>
 	</SERVICE_ENDPOINT>
 	<SERVICE_ENDPOINT>				
 		<HOSTNAME>grid-monitoring.egi.eu</HOSTNAME>
               <GOCDB_PORTAL_URL>https://gocdb4.esc.rl.ac.uk/portal/index.php?Page_Type=View_Object&object_id=21960&grid_id=0</GOCDB_PORTAL_URL>
		<SERVICE_TYPE>egi.SAM</SERVICE_TYPE>
		<HOST_IP />
		<IN_PRODUCTION>Y</IN_PRODUCTION>
		<NODE_MONITORED>Y</NODE_MONITORED>
		<GOCDB_PORTAL_URL>https://gocdb4.esc.rl.ac.uk/portal/index.php?Page_Type=View_Object&object_id=21960&grid_id=0</GOCDB_PORTAL_URL>
	</SERVICE_ENDPOINT>
       </VIRTUAL_SITE>
</RESULTS>

get_virtual_sites_roles

Parameters:

  • dn - Limit results to user with given certificate DN

Output:

<RESULTS>
	<VIRTUAL_SITE PRIMARY_KEY="157G0">
		<NAME>ALL_OPS_TOOLS</NAME>
		<DESCRIPTION>All central instances of the EGI operational tools</DESCRIPTION>
		<EMAIL>John.Casson@stfc.ac.uk</EMAIL>
		<MONITORED>Y</MONITORED>	
		<GOCDB_PORTAL_URL>https://gocdb4.esc.rl.ac.uk/portal/index.php?Page_Type=View_Object&object_id=21960&grid_id=0</GOCDB_PORTAL_URL>
		<USER>
			<FORENAME>Diego</FORENAME>
			<SURNAME>Carvalho</SURNAME>
			<CERTDN>/C=BR/O=ICPEDU/O=UFF BrGrid CA/O=CEFET-RJ/OU=DEPES/CN=Diego Carvalho</CERTDN>
			<GOCDB_PORTAL_URL>https://gocdb4.esc.rl.ac.uk/portal/index.php?Page_Type=View_Object&object_id=21960&grid_id=0</GOCDB_PORTAL_URL>
			<USER_ROLE>
				<USER_ROLE>Virtual Site Administrator</USER_ROLE>
				<ON_ENTITY>ALL_OPS_TOOLS</ON_ENTITY>
				<ENTITY_TYPE>Virtual Site</ENTITY_TYPE>
			</USER_ROLE>
		</USER>
	</VIRTUAL_SITE>
</RESULTS>

Limitations

A virtual site cannot hold a service endpoint that doesn't have a parent site.


There is a requirement to group existing Service Endpoints (currently grouped under their corresponding 'owning' physical Site) under a new 'Virtual Site' entity. See: https://rt.egi.eu/rt/Ticket/Display.html?id=987 and https://wiki.egi.eu/wiki/Logical-site

  • At present, the proposed features of a VSite will include (see Media:VirtualSitesDesign.pdf‎):
    • A VSite will be a separate GOCDB entity, and will have users and other attributes much like an existing physical site but with different rules (described below). Importantly, we believe this grouping has to be a new gocdb object in order to clearly define the intended semantics of the grouping (e.g. both a 'VSite' and an imaginary 'VService' could both group many SEs, but a VSite has very different semantics to a VService !).
    • A VSite will be used to group existing Service Endpoints only (i.e. SEs that have already been created under their owning physical Site).
    • A VSite cannot group new SEs that have no owning physical site.
    • A single SE may only have a single parent physical Site (i.e. GOCDB cardinality of 1 between Site and SE)
    • A single SE can have many parent VSites (requires GOCDB cardinality of 'many-to-many' between Virtual Site and SE).
    • New PI queries are proposed to support querying of VSites and querying of SEs that are grouped under a VSite (much like the existing get_site and get_service_endpoint methods (https://wiki.egi.eu/wiki/GOCDB/PI/get_service_endpoint_method and https://wiki.egi.eu/wiki/GOCDB/PI/get_site_method ). The following XML example is related: https://twiki.cern.ch/twiki/pub/Main/ATPVOFeeds/atp_vo_feed_example.xml
    • The permissions model requirements for a VSite are not yet well defined. It is currently proposed that users with a role over the owning physical site should maintain their cascading permissions over their SEs (i.e. no modification to the current site/permissions model). Conversely, users with a VSite role will not gain any cascading permissions over the SEs; this has the following important implications;
      • A VSite could not be used to declare a downtime for all its member SEs.
      • Similarly, users with a role over the VS will not be able to update/modify a member SE.
      • If VSite permissions are required (e.g. for declaring SE downtimes and modifying SEs), then a user may have to request a physical site role. These requirements are currently undefined.