GOCDB/Release4/Development/VSites
Jump to navigation
Jump to search
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.