Difference between revisions of "GOCDB/Release4/Development/VSites"
Line 13: | Line 13: | ||
===Virtual Site Entity=== | ===Virtual Site Entity=== | ||
A virtual site is a new GOCDB entity | A virtual site is a new GOCDB entity containing the following information: | ||
* Name | * Name | ||
Line 21: | Line 21: | ||
* Child service endpoints | * Child service endpoints | ||
* Roles held over the virtual site | * 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 | |||
Example Output: | |||
<code> | |||
<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> | |||
</code> | |||
===Limitations=== | |||
A virtual site cannot hold a service endpoint that doesn't have a parent site. | |||
Revision as of 15:17, 20 January 2012
<< 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.
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
Example 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>
<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>
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.