Difference between revisions of "VRE Manager"

Revision as of 15:53, 29 October 2008

The VREManager is a gCube Service offering 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.

Design

Within the gCube architecture, the VREManager 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.

The VREManager adopts the Singleton pattern and it exposes a single port-type, gcube/vremanagement/vremanager/VREManager. Clients may manipulate GCUBEResources within the scope and get back information about what's going on by using the operations of such a port-type.

Manipulating a resource means to add or remove it from the scope managed by the VREManager instance. Howvere, there is one exception: the service resource. This type of resource represents a bunch of packages stored in the Software Repository ready to be deployed. When a client asks to the VREManager to add a service to its scope, the VREManager creates a new instance of that service and joins such an instance to its scope.

Interface

The operations exposed by the VREManager port-type are:

• AddResources - ...
• AddResources - ...
• GetReport - ...
• SendReport - ...

The public interface of the VREManager port-type can be found here.

Resource Report

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

For each service, information about the service's dependencies resolution and package deployment are reported.

Possible dependencies states are:

• SUCCESS: all the dependencies have been successfully resolved
• FAILED: some dependencies are missing

Periodically, the Deployer service sends a report on the deployment activity (performed asynchronously with respect to the VREManager request). Such report has a state:

• OPEN: the activity is still ongoing, other reports will follow
• CLOSED : the activity is closed, no further report will be sent

Possible package states are:

• WAITING: request is still pending
• ALREADYDEPLOYED: the package was already available on the target gHN
• SKIPPED: the package was not deployed due to an error in another service from which it depends on
• FAILED: the deployment failed
• DEPLOYED: the package has been deployed
• ACTIVATED: the package has been activated
• RUNNING: the related instance is running

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"?>
<ResourceReport>
  <ID>4522f7c0-a54c-11dd-8525-e7e836b0fdde</ID>
  <LastUpdate>2008-10-29T00:58:17+01:00</LastUpdate>
  <TargetScope>/gcube/devsec</TargetScope>
  <Services>
    <Service>
      <Class>InformationSystem</Class>
      <Name>IS-Notifier</Name>
      <Version>1.00.00</Version>
      <DependenciesResolutionStatus>SUCCESS</DependenciesResolutionStatus>
      <DeployedOn>9bf172d0-a30c-11dd-88bf-83f7edc13611</DeployedOn>
      <ErrorDescription>-</ErrorDescription>
      <DependenciesResolution>
        <ResolvedDependencies>
          <Dependency>
            <ServiceClass>InformationSystem</ServiceClass>
            <ServiceName>IS-Notifier</ServiceName>
            <ServiceVersion>1.00.00</ServiceVersion>
            <PackageName>Notifier-service</PackageName>
            <PackageVersion>1.01.00</PackageVersion>
          </Dependency>
          <Dependency>
            <ServiceClass>InformationSystem</ServiceClass>
            <ServiceName>IS-Notifier</ServiceName>
            <ServiceVersion>1.00.00</ServiceVersion>
            <PackageName>Notifier-stubs</PackageName>
            <PackageVersion>1.00.01</PackageVersion>
          </Dependency>
        </ResolvedDependencies>
        <MissingDependencies/>
      </DependenciesResolution>
    </Service>
  </Services>
  <DeploymentActivity>
    <GHN>
      <Host>dlib33.isti.cnr.it:8001</Host>
      <ID>9bf172d0-a30c-11dd-88bf-83f7edc13611</ID>
      <LastReportReceivedOn>2008-10-29T00:58:16+01:00</LastReportReceivedOn>
      <LastReportReceived>
        <Status>OPEN</Status>
        <Packages>
          <Package>
            <ServiceClass>InformationSystem</ServiceClass>
            <ServiceName>IS-Notifier</ServiceName>
            <ServiceVersion>1.00.00</ServiceVersion>
            <PackageName>Notifier-service</PackageName>
            <PackageVersion>1.01.00</PackageVersion>
            <Status>FAILED</Status>
            <Message>The package has NOT been successfully deployed. Possible cause: unable to deploy because of a RI of the service is already deployed on this node</Message>
          </Package>
          <Package>
            <ServiceClass>InformationSystem</ServiceClass>
            <ServiceName>IS-Notifier</ServiceName>
            <ServiceVersion>1.00.00</ServiceVersion>
            <PackageName>Notifier-stubs</PackageName>
            <PackageVersion>1.00.01</PackageVersion>
            <Status>SKIPPED</Status>
            <Message>The package could not be deployed because it depends on a package which has an error</Message>
          </Package>
        </Packages>
      </LastReportReceived>
    </GHN>
  </DeploymentActivity>
  <Resources/>
</ResourceReport>

Sample Usage

In the following, an explanation of the usage of each VREManager operation is provided.

Adding Resources and Services to VRE

The AddResource operation can be invoked as follows:

...
import org.gcube.vremanagement.vremanager.stubs.vremanager.AddResourcesParameters;
import org.gcube.vremanagement.vremanager.stubs.vremanager.ServiceItem;
import org.gcube.vremanagement.vremanager.stubs.vremanager.ServiceList;
import org.gcube.vremanagement.vremanager.stubs.vremanager.VREManagerPortType;
import org.gcube.vremanagement.vremanager.stubs.vremanager.service.VREManagerServiceAddressingLocator;
...

EndpointReferenceType endpoint = new EndpointReferenceType();
		
try {
	endpoint.setAddress(new Address("http://"+ <VREManager hostname>+":"+ <VREManager port> +"/wsrf/services/gcube/vremanagement/VREManager"));
	VREManagerPortType pt;

	GCUBESecurityManagerImpl managerSec = new GCUBESecurityManagerImpl() {  
		public boolean isSecurityEnabled() {return false;}};
	pt = GCUBERemotePortTypeContext.getProxy(new VREManagerServiceAddressingLocator().getVREManagerPortTypePort(endpoint), 
	GCUBEScope.getScope(...,managerSec);
					
	AddResourcesParameters add = new AddResourcesParameters();	
	ServiceItem[] servicelist = new ServiceItem[2];
	for (int i = 1 ; i < 2; i++) {
		servicelist[i-1] = new ServiceItem();
		servicelist[i-1].setServiceClass(...);
		servicelist[i-1].setServiceName(...);
		servicelist[i-1].setServiceVersion(...);
		servicelist[i-1].setGHN(...); //forces target gHN for the service
	}
			
	ServiceList l = new ServiceList();
	l.setService(servicelist);
	add.setServices(l);
	pt.addResources(add);
} catch (Exception e) {
	//managing the error
}

Removing Resources and Services from VRE

Getting the Resources 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
|-getreport.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 an instance of the two given services 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.

It returns the report ID that can be used to invoke the GetReport operation.

GetReport

The GetReport script invokes the GetReport operation to retrieve a Resource Report. It must be executed as follows

./getreport.sh <VREManager host> <VREManager port> <caller scope> <report ID>

This request will print out the resource report related to the given report ID.