Overview

The objective of this report is to present the current status and future plans of the tools developed by CERN in the context of the D4Science-II SA1 work package to operate the project production infrastructure. These tools support different infrastructure operation activities with the common goal of improving the infrastructure availability and the quality of service delivered to the infrastructure users. The work on developing and running tools for the D4Science infrastructure can be categorised in four main areas:

Infrastructure Monitoring
The monitoring of the D4Science production infrastructure is a central activity within the infrastructure operation tasks. It is based on a number of different tools developed or adopted by the project. Since the beginning of the project these tools have been gradually deployed in the production infrastructure. They can and can be grouped in two categories: (1) based on information collected by the gCube Information System, (2) based on information produced/consumed by the gCube Messaging System.

Infrastructure Accounting
Also important in a production quality infrastructure is the collection of accounting data. This data should cover not only the users’ exploitation of the infrastructure but also the internal service-to-service communications. To gather and visualize the infrastructure accounting data the gCube Messaging System solution, already exploited for the monitoring of the infrastructure, was also used.

Infrastructure Services Availability
The infrastructure monitoring solutions provide useful detailed information about each resource of the infrastructure. However to have a complete control over the infrastructure it is also important to understand the status of the infrastructure functionality. The infrastructure service availability (SAM) is a plug-in based solution that focus on testing the status of the key functional areas provided by the D4Science infrastructure (e.g. the search framework). It is based on the gCube Executor service.

Infrastructure Management
In the area of Infrastructure Management, the gCube software provides many facilities for the automatic software lifecycle: they allow dynamic software deployment , undeployment and upgrade. The management of an infrastructure and as well of a site has been implemented so far trough graphical interfaces, requiring in advance the installation of a portal. In addition those graphical tools does not allow complex infrastructure task as VO or the whole infrastructure upgrade. In order to support administrators, new tools have planned to be implemented to extend both the portlets and CLIs already present in gCube.

To better explained these different tools it is important first to present the D4Science infrastructure itself and the gCube software that supports it.

D4Science Infrastructure

The D4Science production infrastructure is the set of hardware and software resources deployed to provide the D4Science user communities with a reliable service for their production activities. The infrastructure supports several scientific scenarios: AquaMaps, FCPPS, ICIS, INSPIRE, and DRIVER.

The production activities of each community are executed in controlled workspaces. These workspaces are called Virtual Research Environments (VREs). VREs are collaborative environments created on-demand allowing remote sharing of applications, services and data resources. From the operational point of view, to support the creation and management of these VREs, the infrastructure is organized in 2 types of nodes:

• gCube nodes: run the gCube software as released by D4Science SA3 work package. gCube allows the definition, hosting and maintenance of VREs;
• gLite nodes: run the gLite middleware as released by the EGEE project. gLite enables sharing of computational and storage capabilities.

Even if both node types share some operational procedures, due to their different nature, the management of each node type is based on an independent set of operational procedures. This separation of procedures is consequently also visible in the distinct monitoring and accounting procedures for gLite nodes and gCube nodes. The monitoring and accounting of gCube nodes is based on the gCube technology and it’s explained in detail in the following sections of this report. The monitoring and accounting of the gLite nodes is based on tools defined and provided by the EGEE project, such as the GOCBD, SAM, and GSTAT.

gCube System

gCube is a software system resulting from the combination in a Service Oriented Architecture (SOA) of a number of subsystems. The gCube system can be schematized by the reference architecture presented in the diagram below:

Such subsystems are organised in a three-tier architecture consisting of:

• The gCube run-time environment, named gCube Hosting Node environment or simply gHN. Is the set of base subsystems equipping each gCube node and forming the platform for the hosting and operation of the other system constituents. It contains the gCube container (to run gCube services), the gCore Framework (to reinforce the gCube container in supporting the operation of gCube services), and a number of local services, libraries, and stubs needed to manage the communication with the other gCube services;
• The gCube infrastructure enabling services is the set of subsystems constituting the backbone of the gCube system and responsible to implement (1) the operation of an e-Infrastructure supporting resources sharing and (2) the definition and operation of Virtual Organizations and Virtual Research Environments;
• The gCube application services is the set of subsystems implementing facilities for (1) storage, organisation, description and annotation of information in a VRE, (2) retrieval of information in the context of a VRE and (3) provision of VO and VRE users with an interface for accessing such an e-Infrastructure.

A key aspect of the gCube system is the fact that all elements composing the infrastructure are seen as resources and are represented in the gCube Information System in a common way. This is a clear advantage form the infrastructure operational perceptive since all infrastructure resources can be managed in the same way. The following resource types are currently supported: Services, Software, Libraries, Third Party Libraries, gLite Nodes, gHN Nodes, Running Instances, External Running Instances, and Application Specific Resources.

gCube Information System

The gCube IS subsystem allows the publication of descriptive information about VRE resources, the discovery of VRE resources based on descriptive information, and the real-time monitoring of VRE resources based on subscription/notification mechanisms. Heavily used by all functional layers of gCube, the IS is a replicated service whose instances communicate in peer- to-peer fashion to maximize availability, response time, and fault tolerance. The IS plays a central role in a gCube-based Infrastructure by implementing the features supporting the publishing, discovery and real-time monitoring of the set of resources forming a gCube-based infrastructure. It acts as the registry of the infrastructure, i.e. all the resources are registered there and every service of the infrastructure must refer to it to dynamically discover the other infrastructure constituents.

The gCube IS subsystem is composed by different components:

• Components for production/publishing:
  • IS-Registry – This service supports the publishing/unpublishing of gCube resources. A gCube resource is advertised through its profile;
  • IS-gLiteBridge – This service supports the publishing/unpublishing of gLite resources gathered from the EGEE production infrastructure;
  • IS-Publisher – This library supports services in publishing/unpublishing groups of resource properties and registering/unregistering groups of topics;
• Components for collection/storage:
  • IS-IC – This service aggregates the information published in the IS. Form a logical point of view it is a global registry but, because of the expected quality of service, it has been designed to support a federation model;
• Components for consumption/query:
  • IS-Client – This library supports services in retrieving information published in the IS. It supports the discovery of profiles and properties;
  • IS-Notifier – This service supports other services in subscribing/unsubscribing to topics produced by the other gCube services;
  • IS-Monitoring – This component provides portlet interfaces to visualize the information gathered in the IS.

gCube Messaging System

The overall idea with a Messaging System is that it acts as a message mediator between message senders and message receivers. This mediation provides a new level of loose coupling for messaging. At a high level, messages are a unit of business information that is sent from one application to another via the MS. Applications send and receive messages via a MS using what are known as destinations. Messages are delivered to receivers that connect or subscribe to the messages.

This is the mechanism that allows for loose coupling between senders and receivers, as there is no requirement for each to be connected to the MS for sending and receiving messages. Senders know nothing about receivers and receives know nothing about senders – asynchronous messaging.

The gCube Messaging subsystem is composed by different components:

• Central Broker:
  • Message Broker – receives and dispatches messages;
• Producer Side:
  • Messages – defines the messages to exchange;
  • Local Producer – provides facilities to send messages from each node;
  • Node Monitoring Probes – produces monitoring info for each node;
  • Node Accounting Probes – produces accounting info for each node;
  • Portal Accounting Probes – produces accounting info for the portal;
  • System Accounting Library – produces custom accounting info related to gCube services;
• Consumer Side:
  • Messaging Consumer – subscribes for messages from the message broker, checks metrics, stores messages, and notifies administrators;
  • Portal Accounting portlet - displays in a portlet interface the portal accounting information;
  • Node Accounting portlet - displays in a portlet interface the node accounting information.
  • Monitoring portlet - displays in a portlet interface the monitoring information as gathered by Monitoring probes, and displays notification history

More details on the gCube Messaging System can be found at: https://gcube.wiki.gcube-system.org/gcube/index.php/Messaging_Infrastructure

Infrastructure Monitoring

The goal of the infrastructure monitoring tools is to continuously monitor the status of the infrastructure and provide the relevant infrastructure status information to the appropriate persons managing/using the infrastructure. This functionality is based on two sets of tools: (1) based in information collected by the gCube Information System, (2) based in information produced/consumed by the gCube Messaging System.

The gCube IS subsystem provides a number of tools to monitor the resources available in the D4Science production. These monitoring solutions rely on centralized information hosted in the IS service. It is extremely powerful since it provides a complete and comprehensive view over the status of the system. Furthermore it can also be easily customized by querying the IS for information about specific resources (or combination of different resources) and can provide organized views over the IS content for individual VOs. The gCube Information System provides 3 tools to monitor the infrastructure status: gCube Live Monitoring, gCube Infrastructure Viewer, and gCube Resource Management.

The gCube messaging subsystem provides a fully distributed solution, with different types of probes deployed in all infrastructure nodes, producing continuous information to a central messaging broker. This information is then processed by a consumer service. From the infrastructure monitoring point of view the gCube messaging consumer services is used to generate automatic notifications about infrastructure problems and to provide summary information about infrastructure problems.

gCube IS Live Monitoring

The gCube live monitoring tool allows to access resource profiles, as they are stored in the gCube Information System. Colours and error messages are used to highlight the resources that are not properly exploitable by the services of the infrastructure. Some example: if a gHN is uncertified the tool reports the last time the gHN worked properly, if a service running instances is unreachable it is highlighted in red to simplify its identification. The picture below provides examples of uncertified gHNs and unreachable running instance resources.

The gCube live monitoring tool not only allows to identify resources that are failing but also to access each resource profile to inspect the status of the resource, how it was configured, and all its properties.

The gCube live monitoring tool is accessible at: http://monitor.d4science.research-infrastructures.eu/monitoring

gCube IS Infrastructure Viewer

The gCube infrastructure viewer provides simplified views of the status of the infrastructure, easily consumable from any web-enabled device. It exploits Treemap technology to display hierarchical (tree-structured) resources as a set of nested rectangles. Each resource is represented as a rectangle, which is then tiled with smaller rectangles representing sub-resources. Each rectangle has an area proportional to a specified dimension on the resource. The rectangle, its border or its title are coloured to highlight additional information about the resource.

When the colour and size dimensions are correlated in some way with the tree structure, an administrator can often easily see patterns that would be difficult to spot in other ways. Moreover making an efficient use of space this tool can legibly display thousands of items on the screen simultaneously.

The gCube IV provides access to six different views:

• GHN view represents sites and gHNs characterized by the RIs;
• Services view represents class of services, services, and RIs;
• Data view represents collections, metadata collections, and indexes;
• Package view represents the packages distribution on the infrastructure gHNs;
• Package dependencies view represents the distribution packages dependencies;
• Services dependencies view represents the services functional dependencies.

Different metrics and different status information are available for the different views. Common to all views is the position of the interface main elements: the address bar, control panel, legend, etc. The figure below provides an example of the gHN view and depicts the location of the main interface elements.

After the identification of an error, a warning, or unavailability of some resources it is possible to collect more information about the problem by clicking on the rectangle reporting the issue. A detailed panel is displayed that contains the resource specific information required to understand and correct the infrastructural problem.

The gCube IV for the D4Science production infrastructure is accessible at: http://monitor.d4science.research-infrastructures.eu/iv

gCube IS Resource Management

The gCube resource management is a very powerful tool and can be used in two modes:

• Standalone – read-only version offering the possibility to browse the content of the gCube information system;
• Portal – read-and-write version allowing management operations on the infrastructure.

For monitoring purpose only the standalone version of the resource management tool is used. The figure below provides an example of the look and feel of this tool.

The gCube Resource Management is composed by several panels: Main Menu, Resource Navigation, Resource List, Profiles, Related Resources. The main menu shows information about the selected scope and details on the resource list. In addiction it offers the possibility to select a different scope of the infrastructure, to refresh the panels’ information and to find a gCube resource giving the ID. The resource navigation panel gives the possibility to select among two types of resources:

• gCube Resources
• gCube WS-Resources

A click on a resource category causes the portlet to show the list of available resources of that category for the current scope in the resource list panel. From the resource list panel is then possible to retrieve two types of information:

• The gCube resource profile corresponding to the selected gCube Resource/WS-resource. The dedicated profiles paned displays it in a tree, with the possibility to view it as xml formatted text;
• The list of related resources. Depending on the resource type the kind of information displayed is different:
  • Collection: lists all related metadata collections;
  • gCube Hosting Node: lists all related RIs running in the specified node;
  • Metadata Collection: lists all related indexes;
  • Software: lists all deployed instances of the specified software;
  • Running Instance: lists all related gHNs;
  • WSResource: lists all related RIs that publishes the WS-Resource.

The gCube resource management is accessible at: http://monitor.d4science.research-infrastructures.eu/rm

gCube Monitoring Messaging Consumer

Automatic notifications are produced by the consumer service based the information produced by the monitoring probes deployed in all nodes of the infrastructure. The monitoring probes can be of two types: gHN and Running Instance (RI). A gHN probe produces messages related to the gHN node itself while the RI probe produces messages concerning the gCube services running on the gHN. The following probes are currently available:

1. GHNDiskProbe – monitors the local available disk space;
2. GHNLoadProbe – monitors the CPU load of the gHN;
3. GHNMemoryProbe – monitors the memory available on the gHN;
4. GHNInformationProbe – gathers information related to the gHN HW;
5. GHNNotificationProbe – subscribes for local gHN events (scope changed, scope added, node start, etc);
6. RINotificationProbe – subscribes for local RI events (scope changed, scope added, deployment, etc).

All the above probes exploit the GCUBELocalProducer to contact the Message Broker and send messages. Probes can also be grouped according to types of message that they produce and according to their behaviour:

• Test Probes – Perform local tests on the gHN and send messages containing the test results. Probes 1 to 4 above.
• Notification Probes – Exploits the gCF local event mechanism to consume events related to GHN/RI actions (GHN Ready, RI/GHN scope changed, etc). Probes 5 and 6 above.

The Consumer Monitor is a gCube WSRF service that is deployed on the infrastructure to consume messages coming from Message Brokers. The main features of the service are:

• Subscribe to monitoring/accounting messages for different scopes;
• Check monitoring message test result against metrics;
• Store monitoring/accounting messages on local database;
• Send email notifications to admins in case of abnormal tests results;
• Provides a GUI with summary information.

An important functionality of the Messaging Consumer is the capability to send notifications and daily reports to administrators by elaborating on the stored incoming messages. The administrators are selected trough a local configuration file, directly retrieved from VOMS, or by a configuration file stored on IS. The Messaging Consumer is configured to send email notification in the following situations:

• When a message of type NOTIFICATION with HIGH priority (e.g. gHN start, shutdown) is received;
• When a message of type TEST and the test result exceed some threshold parameters (e.g. CPU usage, disk quota) is received;
• Once per day a summary report of all received notifications,

The Messaging Consumer also embeds a Jetty web server in order to publish daily report. The first version of the report GUI, allows admins to navigate trough reports grouped by day, scope, gHN name, and shows the related notification sent by the service.

The Monitoring portlet processes the information coming from Monitoring and Notification DBs and displays it as in the example below.

Development Status

The information reported in the table only covers the gCube messaging consumer as the other monitoring tools are not developed by CERN.

Date	Release	gCube	Status	Description
20 Sep 2009	1.0.0	1.3.0	Done	first release
16 Oct 2009	1.0.1	1.4.0	Done	bug fix on reconnection to broker bug fix on problems with JSON queries
30 Nov 2009	1.1.0	1.6.0	Done	added threshold values in generic resources support for external mysql database
15 Jul 2010	1.2.0	1.9.0	Done	email notifications sent to site managers new summary report with daily problems update summary email organizing the information by notification type
08 Feb 2011	1.3.0	2.3.0	Done	Added Supported Subscription on RI Specific data. Automatic RI filtering on High level calls Monitoring portlet implementation
Q1/2011	1.4.0	2.x.x	Planned	retrieve list of users from Liferay porta

Infrastructure Accounting

The goal of the infrastructure accounting is to provide reliable information about the exploitation of the D4Science infrastructure that can be easily consumed by the appropriate infrastructure administrators. This functionality is based on information produced/consumed by the gCube Messaging System.

Node Accounting

The information about node accounting is provided to infrastructure administrators through the node accounting portlet. This data is produced by the node accounting probes deployed in all nodes of the infrastructure. The node accounting probe is in charge of collecting information about local usage of gCube services. The probe is a library deployed on each gHN that exploits the mechanisms offered by gCF to understand the usage of the services on the infrastructure. For each incoming method call, gCF produces a record log as follows:

END CALL FROM (146.48.85.127) TO (Messaging:Consumer:queryAccountingDB),/d4science.research-infrastructures.eu,Thread[ServiceThread-1039,5,main],[0.847]

Each “END CALL” line contains information about: time, running instance invoked, method invoked, caller scope, invocation time and Caller IP . The probe parses this type of log files every aggregation interval (configurable) and aggregates information per running instance. In particular the information is aggregated following this schema: RI -> CallerScope -> CallerIP -> Number of Invocations and Average Invocation Time. The information about the invoked method is not parsed since it has been decided not to expose this granularity of information.

At the end of the aggregation process, the probe creates node accounting messages that are sequentially send to the Message Broker using the Local Producer. For this particular type of messages a queue receiver is exploited on Message Broker side.

The node accounting portlet processes this information and displays it as in the example below.

Portal Accounting

The information about portal accounting is provided to infrastructure administrators through the portal accounting portlet. This data is produced by the portal accounting probe deployed in portal node of the infrastructure. The portal accounting probe is in charge of aggregating information about portal usage. As for the node accounting, the portal (and in particular the ASL library) produces a log record, describing the following operations:

• Login
• Browse collection
• Simple search
• Advanced search
• Content retrieval
• Quick Search
• Archive Import scipts creation,publication and running.
• Workspace items operations
• Time Series import,removal, curation
• Annotation creation,removal, update

This is an example of one log record produced by the D4science portal:

2009-09-03 12:22:37, VRE -> EM/GCM, USER -> andrea.manzi, ENTRY_TYPE -> Simple_Search, MESSAGE -> collectionName = Earth images 
AND collectionID = 12345 | collectionName = Landsat 7 AND collectionID = 54321 | term = satellite

The common information between each type of log is: time, user, VRE, operation type, message. The message part differs between each type of log record, for example for the simple search record contains info about the collections included in the operation and term searched. The portal accounting probe aggregates portal accounting information by creating a number of Portal Accounting messages aggregated by: User -> VRE -> OperationType. Each message contains a certain number of records of one OperationType.

As in node accounting, at the end of the aggregation process the probe sequentially sends to the Message Broker using the Local Producer a number of portal accounting messages. For this particular type of messages a queue receiver is exploited on Message Broker side.

The portal accounting portlet processes this information and displays it as in the example below.

System Accounting

The goal of the System Accounting is to allow any gCube service or client to account their own custom information within the D4science infrastructure

As the other type of accounting, it exploits the Messaging Infrastructure to deliver the message containing the accounting info to the proper instance of the Messaging Consumer for storage and future querying.

In particular each time a new Accounting Info is generated using the System Accounting Library a new message is enqueued into the Local Producer which is in charge to dispatch it to the proper Message Broker instance. The Consumers in charge to process this kind of message, will then be notified and will store the information into their System Accounting DBs. Each type of message is considered as a new table on the System Accounting DB.

The System Accounting Library contains methods for the generation of System Accounting information, both within gCube services and gCube clients. The querying facilities have been implemented inside the Consumer library which is the entry point for any kind of information retrieval related to accounting and monitoring.

Development Status

Date	Release	gCube	Status	Description
01 Oct 2009	1.0	1.3.0	Done	portal and node accounting first release
30 Nov 2009	1.1.0	1.6.0	Done	added caller IP parsing on node accounting new portal accounting probes for content, quick search, and google search
30 Jan 2010	1.2.0	1.7.0	Done	release of the portal accounting portlet supporting content, quick search, and google search
23 Feb 2010	1.2.1	1.7.2	Done	implemented a banned list in order to filter out unwanted users from portal accounting probe
14 May 2010	1.3.0	1.8.0	Done	publishing node accounting info in gCube IS new portal accounting probes for time series, home library, and archive import portal accounting portlet extension for time series, home library, and archive import
15 Jul 2010	1.4.0	1.9.0	Done	new node accounting portlet modified portal accounting portlet to Liferay portal
3 Sept 2010	1.4.1	2.0.0	Done	add graph visualization to the node accounting portlet
22 Oct 2010	1.5.0	2.1.0	Done	new portal accounting probes for Annotation portets portal accounting portlet extension for annotation
08 Feb 2011	1.6.0	2.3.0	Done	System Accounting Library and extension to Messaging Consumer to handle System Accounting Messages System Accounting queries extension for the Consumer Library
Q2/2011	1.x.x	2.x.x	Planned	new portal accounting probes for aquamaps, reports portlets, ASL OAI_PMH, Abstract Search portal accounting portlet extension for aquamaps, reports,ASL OAI_PMH, Abstract Search

Infrastructure Services Availability

The goal of the Infrastructure Services Availability is to provide a reliable tool to continuously verify the status of the infrastructure service (i.e. if the infrastructure functionality works as expected). This tool is based on gCube Executor service and on tailored plug-ins that verify the infrastructure functionality.

SAM Test Plug-Ins

Being gCube a SOA infrastructure the natural way to test the availability of the infrastructure was to implement a new service responsible for the execution of such tests. This service must be highly configurable with the possibility to dynamic inject and configure new tests. However looking on what was already available in the gCube framework, it was decided to exploit the plug-in mechanism offered by the gCube Executor Service (https://gcube.wiki.gcube-system.org/gcube/index.php/Executor). This service is responsible of the execution of gCube tasks, i.e. bodies of code that lack a network interface but can be dynamically deployed into the service and executed through its interface. gCube tasks, in this case SAM tests, are designed, packaged, and deployed as plug-ins of the Executor service.

The outcome of the execution of these SAM test plug-ins is provided to infrastructure administrators through the SAM portlet (to be released soon). This data is gathered from a pre-defined location where all SAM plug-ins store the output of their execution.

Concerning the plug-ins itself these can be seen as specific tests focused on concrete functional areas of the infrastructure. They recreate a number of invocations to a set of services that provide a given functionality. These invocations represent the standard usage of the infrastructure can can be executed periodically. The following plug-ins are planned to be implemented:

• Search Framework;
• Information System;
• Index Lookup.

Search Framework
The Search Framework plug-in was released as part of gCube 1.8. This plug-in tests the gCube Search Framework as exposed by the ASL HTTP API. This means that search invocations are not directly performed to gCube Search service but instead to the ASL framework search HTTP API. The ASL HTTP API gives also the possibility to gather information about gCube collections and metadata collections for each scope and extract the related schema, language, browsable, sortable, and searchable fields. All this information is then used as input for the following search tests:

• Quick search test
• Combined search test
• Browse test
• Simple search Test

Information System
The Information System plug-in tests the availability of the gCube Information System. As any other information system, the gCube IS exposes interfaces for information publication and querying. Two operations are implemented by two different services behind (IS-Registry and IS-Collector). The gCube infrastructure hides services deployment details (distribution and replication) by offering libraries to client for publication and querying (IS-Publisher and IS-Client). Given that the scope of the availability test is to check the status of any instance of IS services running on a given VO, the IS plug-in contacts directly all possible instances of the IS services (without the abstract layer offered by IS libraries) running the following tests:

• GCUBE profile publication/removal/update tests
• Query test tests (sequential/parallel)
• WS-resource publication/removal tests

Index Lookup
The gCube search functionality is based (apart from gCube Search services) on the availability of gCube Index Lookup services. gCube Index Lookups are divided into three different implementations:

• Full Text Index Lookups (responsible for full text search)
• Fwd Index Lookups (responsible for collection browsing)
• Geo Index Lookups (responsible for geo referential search)

The Index Lookup plug-in tests the availability of these class of services. It relies on the gCube IS to understand what are the available collections and the corresponding indexes to be tested. The tests performed are:

• Lookup Index availability tests (checks for each collection if at least one Lookup Index is available)
• Lookup Index Query performance tests

CM Service

The CM Service ( still under integration within gCube) is the new service ( replacement of the Content Management stack of services currently integrated in gCube) which offers homogeneous access to content stored in arbitrarily located and typed repositories. It is designed to adapt multiple back types to the gDoc access type (https://gcube.wiki.gcube-system.org/gcube/index.php/Content_Manager_%28NEW%29#Content_Model) using an open architecture of type-specific plugins. The available plugins implemented so far are:

• SMS Plugin
• OAI-PMH Plugin

The CM Tester is responsible for the availability testing of the CM service, which means performing I/O tests over the available CM instances in the D4science infrastructure:

• Read operations
  • For each collection in the system both single/bulk read operations are tested
  • For each operation the related performance is calculated
• Write operations
  • A collection of document is created and single/bulk documents imports are tested
  • For each operation the related performance is calculated

Development Status

Date	Release	gCube	Status	Description
15 May 2010	1.0.0	1.8.0	Done	new search framework plug-in
25 Jun 2010	1.0.1	1.8.1	Done	support for scheduled execution on search framework plug-in
03 Sep 2010	1.1.0	2.0.0	Done	new SAM portlet to show execution results to VO Admins and VRE Managers first release of the SAM report library (hides DB implementation to plug-ins and portlet)
22 Oct 2010	1.2.0	2.1.0	Done	new IS plug-in
Q1/2011	1.x.x	2.x.x	Planned	new Index and CM plug-ins

Infrastructure Management

As already discussed on the introduction, the implementation of tools for gCube Infrastructure Management has been planned to ease the handling of complex infrastructure tasks as the VO or the whole infrastructure upgrade.

Resource Manager Client

The Resource Manager Client library is a set of CLI utilities which allows the management of a gCube infrastructure. It exploits and combines the functionalities exposed by the Resource Manager Service, giving Site/Infrastructure Administrators a powerful tool to easily perform the following infrastructure management operations:

• Service Deployment
• Service Undeployment
• Service Upgrade
• Add Scope to a Resource
• Remove Scope from a Resource

For each operation the Resource Manager Service report is automatically parsed reporting the user possible errors and/or successful executions.

The whole Resource Manager client documentation can be found at (https://gcube.wiki.gcube-system.org/gcube/index.php/Developer%27s_Guide/ResourceManagerClient)

Development Status

Date	Release	gCube	Status	Description
08 Feb 2011	1.0.0	2.3.0	Done	first version handling SAs Deploy, undeploy, upgrade and scope operation