Difference between revisions of "Scope Management"
Manuele.simi (Talk | contribs) (→Static scope for Service) |
Manuele.simi (Talk | contribs) (→Dynamic scope for gHN) |
||
| Line 173: | Line 173: | ||
=== Dynamic scope for gHN === | === Dynamic scope for gHN === | ||
| + | |||
| + | * ''DEF)'' + ''GHN2)'' => model GHN scope as a list of one GI and zero or more VOs. | ||
| + | * on add, enforce ''GHN1)'' and retain only VO from VRE scopes (GCUBEHostingNode) | ||
| + | * on remove, prevent removal of GI if attempted (GCUBEHostingNode) | ||
| + | * on bootstrap, require configuration of single GI and allow zero ore more start VOs (GHNBuilder) | ||
=== Dynamic scope for WS-Resource === | === Dynamic scope for WS-Resource === | ||
Revision as of 17:58, 16 August 2008
[coming soon]
Contents
What's in Scope?
Any gCube resource may only be shared within one or more scopes in the infrastructure on which it is deployed:
Scope is a multi-valued property of all gCube resources.
In addition, we have scope for the state of a specific type of resource, the Running Instance. Therefore, we also have:
Scope is a multi-valued property of WS-Resources generated by Running Instances of gCube services.
Outside its scopes, in particular, a resource can neither be discovered nor used:
Modelling Scope
Three levels of scope may be assigned to a resource: a gCube Infrastructure (GI), a Virtual Organization (VO), or a Virtual Research Environment (VRE).
The levels are hierarchically ordered: GIs are above VOs and VREs are below VOs.
We follow a grammar to denote scopes in a way which formalizes their hierarchical relationships:
SCOPE : = = GI | VO | VRE GI :== /l VO :== GI/l VRE :== VO/l
where l ranges over an alphabet of labels.
For convenience, we write S1 below S2 to indicate that S1 and S2 denote the scope or that S1 is directly or indirectly below S2. Similarly, we write S1 above S2 to indicate that S1 and S2 denote the scope or that S1 is directly or indirectly above S2.
We model scoping as a binary relationship between resource and scopes. We write R in S to denote a pair (R,S) of a resource R and a scope S in the scoping relationship.
Scope Rules
Scoping is constrained by a number of scope rules. Scope rules are specific to resource types. A default rule, however, applies to all of them:
Let VRE range offer virtual research environments, R be a resource and VO virtual organisation.
DEF) if R is shared in a VOs then it is also shared in VREs below: R in VO => for each VRE in VO. R in VRE
- NB: The opposite does not always hold: depending on resource type, a resource may be shared in a VRE but not in the VO above.
- NB: Most definitely, a resource shared in a GI is not automatically shared in the VOs. For this to happen, the resource may have to explicitly join a VO.
Scoping Rules for gCube Hosting Nodes
Let GI range over gCube Infrastructures and GHN be a hosting node.
GHN1) GHN may only be shared in one infrastructure: exist GI. GHN in GI and (GHN in S => S below GI)
GHN2) if a GHN is shared in a scope is also shared above it: GHN in S => for each S' above S. GHN in S'
- NB: GHN2) proves that the converse of DEF) holds for GHNs: A GHN cannot be shared in VRE(VO) if it is not shared also in the VO(GI) above.
gCore implications:
- DEF) + GHN2) => model GHN scope as a list of one GI and zero or more VOs.
- on add, enforce GHN1) and retain only VO from VRE scopes (GCUBEHostingNode)
- on remove, prevent removal of GI if attempted (GCUBEHostingNode)
- on bootstrap, require configuration of single GI and allow zero ore more start VOs (GHNBuilder)
Scoping Rules for gCube Services
Let SV be a gCube Service.
SV1) if SV is shared in a scope it is also shared below it: SV in S => for each S' in S. R in S'
- NB: This extends DEF) to infrastructure-level scope make scoping simplest for services.
gCore implications: none special, scopes are immutable for services (i.e. for the ones already deployed).
Scoping Rules for Running Instances (RIs) of gCube services
Running instances are a first example of resource type for which scoping rules are further constrained by the scope of related resources. In fact, running instances relate to their services and the hosting nodes on which they are deployed.
Let SV(RI) and GHN(RI) denote, respectively, the service of a RI and the GHN on which the RI is deployed.
RI1) RI can only be shared where its GHN and service can: RI in S => GHN(RI) in S and SV(RI) in S
- NB: The opposite of RI1) does not hold: a RI is not necessarily shared wherever its GHN and its service are.
gCore implications:
- on add, enforce RI1) (ServiceContext)
- on startup,
- generic service: subscribe consumer for GHN remove scope events only (ServiceContext) => remove all RI scopes contained in those removed from the GHN (consumer).
- local service: subscribe consumer for GHN remove and add scope events (ServiceContext) => add new GHN scopes to RI (consumer).
- on bootstrap,
- allow JNDI configuration of zero or more start scopes (RIBuilder)
- static only : add all GHN scopes if no start scopes are available (RIBuilder). Prevent in dynamic bootstrap.
Scoping Rules for WS-Resource generated by Running Instances of gCube services
WS-Resources are anther example of resource type for which scoping rules are further constrained by the scope of related resources, in this case the running instance which generate them. Let WSR denote a WS-Resource and RI(WSR) the RI through which has generated WSR.
WSR1) WSR can only be shared where its RI can: WSR in S => RI(WSR) in S
- NB: The opposite of RI1 does not hold: a RI is not necessarily shared wherever its GHN and its service are.
gCore implications:
- on creation, enforce WSR1) (GCUBEHandler)
- on remove, remove from all WS-Resource which have been created by some stateful-port-type of the RI below the removed RI scope;
- due to persistence, cannot be easily performed locally, use instead queries to the IS
Configuring scope (Static scope)
Static scope apllies only for those resources that can be manually created by humans. For such gCube resources, a scope S can be statically (e.g. manually) configured and changed through their appropriate configuration files.
Static scope for gHN
A gHN is always manually deployed, therefore a static scope configuration is always needed. Such a configuration is expressed with two parameters in the $GLOBUS_LOCATION/config/GHNConfig.xml file.
- infrastructure reports the GI the gHN joins (and it can be one and only one, as for GHN1). In the following example, the gHN is configured to join the /gcube infrastructure:
<environment
name="infrastructure"
value="gcube"
type="java.lang.String"
override="false" />
- startScope is a comma-separated list of VOs the gHN joins. These VOs has to be valid VO in the infrastructure (as for GHN2)), otherwise they are ignored. The list of VOs can be an empty list. In the following example, the gHN is configured to join both the /gcube/devsec and the /gcube/testing VO:
<environment
name="startScopes"
value="devsec,testing"
type="java.lang.String"
override="false" />
Static scope for Service
A gCube service has always only static scope(s), specified at service registration time in the Software Repository service.
Static scope for Running Instance
Static scope for RIs has a mean only for those that are manually deployed. A RI can be configured to join one or more VOs and/or VREs with a comma-separated list. Due to RI1), the VOs has to be a subset of the VOs to which the GHN(RI) is joined to and the VREs has to be below the VOs to which the GHN(RI) is joined to.
In order to specify the statis scopes of a RI, insert a startScopes parameter in the service context section of the JNDI's RI as follows:
<service name="gcube/common/vremanagement/Deployer">
<environment
name="configDir"
value="@config.dir@"
type="java.lang.String"
override="false" />
<environment
name="securityManagerClass"
value="org.gcube.common.core.security.GCUBESimpleServiceSecurityManager"
type="java.lang.String"
override="false" />
<environment
name="startScopes"
value="devsec/EM,testing/test1"
type="java.lang.String"
override="false" />
</service>
This parameter is optional: if it is not used, the RI is automatically configured by the gCore to join the VO(s) expressed in the startScopes parameter of the GHNConfig.xml.
Dynamic scope
All the gCube resources can change their scopes due to decisions of humans (so-called Managers) and of lifetime events. This is even more true for WS-Resource that are always dynamically created and destroyed. gCore guarantees that the rules above are respected any time it happens.
Dynamic scope for gHN
- DEF) + GHN2) => model GHN scope as a list of one GI and zero or more VOs.
- on add, enforce GHN1) and retain only VO from VRE scopes (GCUBEHostingNode)
- on remove, prevent removal of GI if attempted (GCUBEHostingNode)
- on bootstrap, require configuration of single GI and allow zero ore more start VOs (GHNBuilder)
Dynamic scope for WS-Resource
- on creation, enforce WSR1) (GCUBEHandler)
- on remove, remove from all WS-Resource which have been created by some stateful-port-type of the RI below the removed RI scope;
- due to persistence, cannot be easily performed locally, use instead queries to the IS
gCube Calls & the gCube Handler
[coming soon]
Scope Managers
[coming soon]
