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.

Difference between revisions of "GOCDB/Release4/Development/VSites"

From EGIWiki
Jump to navigation Jump to search
Line 9: Line 9:
===Cardinality===
===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.
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.
[[File:vsites.png]]


===Virtual Site Entity===
===Virtual Site Entity===

Revision as of 15:13, 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. Vsites.png

Virtual Site Entity

A virtual site is a new GOCDB entity that will store the following information:

  • Name
  • Description
  • Contact E-Mail
  • Monitored flag (Y/N)
  • Child service endpoints
  • Roles held over the virtual 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.