Difference between revisions of "VRE Manager"

Revision as of 01:04, 27 September 2008

The VRE Manager is a gCube Service grouping the facilities for managing the constituents of the VREs, namely the service instances. It is the service in charge to coordinate the overall deployment and operation of each VRE. Moreover, it takes care to interact with the Virtual Organisation Management to create the VO needed to support the operation of the VREs.

Architecture

Within the gCube architecture, the VREManage is placed at the top of a stack of the VREManagement services, below only the VRE Modeler service. Each instance of the service is devoted to manage one and only one specific scope and, within such a scope, it is in charge of adding/updating/removing GCUBEResource. For a detailed explanation about what is a scope and what is in scope, check the Scope Management section of the gCore Developer Guide.

Design

The VREManager adopts the Singleton pattern and it exposes a single port-type, gcube/vremanagement/vremanager/VREManager. Clients may manipulate GCUBEResources within the scope by using the operations of such a port-type.

Basically, ....

Resources Report

After each resource management request, a report is produced by the service.

Possible service states are:

• DEPLOYED: everything was OK
• WAITING: request is still pending
• ALREADYDEPLOYED: the service was already available on the target gHN
• SKIPPED: the service was not deployed due to an error in another service from which it depends on
• FAILED: the service deployment failed

Possible resource states:

• ADDED: the resource was successfully added to the scope
• FAILED: an error occurred and the resource does not join the scope

Sample Report

 <?xml version='1.0' encoding='UTF-8' standalone='yes' ?>
 <Report>
	<Type>DEPLOY</Type>
	<LastUpdate>2008-09-25T16:54:35+02:00</LastUpdate>
	<Packages>
		<Package>
			<ServiceClass>InformationSystem</ServiceClass>
			<ServiceName>IS-Notifier</ServiceName>
			<ServiceVersion>1.00.00</ServiceVersion>
			<PackageName>Notifier-stubs<PackageName>
			<PackageVersion>1.00.00</PackageVersion>
			<Status>DEPLOYED</Status>
			<Host>dlib33.isti.cnr.it:8002</Host>
			<GHN>a938b7d0-88ce-11dd-a38a-f9b09f00a04e</GHN>
		</Package>
		<Package>
			<ServiceClass>DVOS</ServiceClass>
			<ServiceName>AuthorizationService</ServiceName>
			<ServiceVersion>1.00.00</ServiceVersion>
			<PackageName>Stubs</PackageName>
			<PackageVersion>0.00.00</PackageVersion>
			<Status>DEPLOYED</Status>
			<Host>dlib33.isti.cnr.it:8002</Host>
			<GHN>a938b7d0-88ce-11dd-a38a-f9b09f00a04e</GHN>
		</Package>
		<Package>
			<ServiceClass>InformationSystem</ServiceClass>
			<ServiceName>IS-Notifier</ServiceName>
			<ServiceVersion>1.00.00</ServiceVersion>
			<PackageName>Notifier-service</PackageName>
			<PackageVersion>1.00.00</PackageVersion>
			<Status>DEPLOYED</Status>
			<Host>dlib33.isti.cnr.it:8002</Host>
			<GHN>a938b7d0-88ce-11dd-a38a-f9b09f00a04e</GHN>
		</Package>
		<Package>
			<ServiceClass>DVOS</ServiceClass>
			<ServiceName>AuthorizationService</ServiceName>
			<ServiceVersion>1.00.00</ServiceVersion>
			<PackageName>Main</PackageName>
			<PackageVersion>0.00.00</PackageVersion>
			<Status>DEPLOYED</Status>
			<Host>dlib33.isti.cnr.it:8002</Host>
			<GHN>a938b7d0-88ce-11dd-a38a-f9b09f00a04e</GHN>
		</Package>
	</Packages>
 </Report>

Configuration

The only configuration parameter is the Scope in which the instance has to operate in. This can be specified in two ways:

• as static start Scope of the RI (see the releate section on the gCore Developer Guide for details);
• as deployment parameter, in case the VREManager itself is dynamically deployed trough the Deployer facilities.

The test-suite

The VREManager comes with a test-suite package allowing to test its functionalities.The test-suite is completely independent and does not require any other gCube package, except than a local gCore installation. The package is composed by a set of classes, sample configuration files and scripts ready to be executed.

|-lib
|--org.gcube.vremanagement.vremanager.testsuite.jar
|
|-samples
|---...
|
|-addresource.sh
|-...

Each script allows to test one service's operation or a group of operations logically related. In the following each script and its usage are explained.

AddResource

The AddResources script invokes the AddResources operation to add new GCUBEResources on a scope. It must be executed as follows

./addresource.sh <VREManager host> <VREManager port> <configuration file>

Clearly, the VREManager host and port are the information needed to contact the VREManager instance, while the configuration file reports the information about the resources to add or create and the scope in which they have to be managed.

This is an example of configuration file requesting the creation of two resources of type Service:

#global properties
numOfServicesToAdd=2
targetScope=/gcube/devsec
callerScope=/gcube/devsec

# resource list
service.1.name=IS-Notifier
service.1.class=InformationSystem
service.1.version=1.00.00
#GHNID on which the resource will be created
service.1.GHN=a938b7d0-88ce-11dd-a38a-f9b09f00a04e

service.2.name=AuthorizationService
service.2.class=DVOS
service.2.version=1.00.00
#GHNID on which the resource will be created
service.2.GHN=a938b7d0-88ce-11dd-a38a-f9b09f00a04e

This request will trigger the creation of two instances of the given service on the GHN identified by the service.X.GHN parameter.The VREManager is contacted with a call in the scope reported as value of the callerScope parameter and the instances will be created within the targetScope.

This request will generate the printing in the log file of the VREManager instance of a related resource report

The next version of the suite will include the script to directly retrieve the report given its session ID (as returned by the AddResources operation)