Difference between revisions of "Resource Management Specification"

From Gcube Wiki
Jump to: navigation, search
(Key features)
(Key features)
Line 8: Line 8:
  
 
Software resources include a range of entities from packages ready to be deployed to activated services, while hardware resources model anything hosting a service suitable to be exploited by the e-infrastructure.  
 
Software resources include a range of entities from packages ready to be deployed to activated services, while hardware resources model anything hosting a service suitable to be exploited by the e-infrastructure.  
 +
 +
This document outlines their design rationale, key features, and high-level architecture as well as the opportunities they collectively offer.
  
 
=== Key features ===
 
=== Key features ===
  
 
;Dynamic Deployment
 
;Dynamic Deployment
:...
+
:
  
 
;Optimal Resource Allocation
 
;Optimal Resource Allocation
:...
 
 
;Maven Integration
 
 
:...
 
:...
  
Line 24: Line 23:
  
 
;Scalability
 
;Scalability
:...
 
 
;Coordination and Elastic Management
 
 
:...
 
:...
  
 
;Extensible Bridging over Virtual Platforms
 
;Extensible Bridging over Virtual Platforms
 
: A tiny layer, named Virtual Platform, offers an abstract model for transparently interfacing a potentially unlimited number of hosting environments. By extending this model, new platforms can be easily integrated in the existing management facilities and new software resources added to the infrastructure. An extension is also provided to manage Web Applications on Apache Tomcat 6.x
 
: A tiny layer, named Virtual Platform, offers an abstract model for transparently interfacing a potentially unlimited number of hosting environments. By extending this model, new platforms can be easily integrated in the existing management facilities and new software resources added to the infrastructure. An extension is also provided to manage Web Applications on Apache Tomcat 6.x
 +
 +
;Maven Integration
 +
:...
 +
 +
;Coordination and Elastic Management
 +
:...
  
 
== Design ==
 
== Design ==

Revision as of 22:05, 24 February 2012

Overview

Resource management focuses on the optimal exploitation of software and hardware resources.

Software resources include a range of entities from packages ready to be deployed to activated services, while hardware resources model anything hosting a service suitable to be exploited by the e-infrastructure.

This document outlines their design rationale, key features, and high-level architecture as well as the opportunities they collectively offer.

Key features

Dynamic Deployment
Optimal Resource Allocation
...
Node management and Monitoring
Tools for monitoring and managing nodes of the infrastructure are part of the resource management facilities. Local information are collected and published in the Information System as well as returned on demand. Web Service interfaces exposed by locally hosted services allow to remotely reconfigure the node upon the needs of the infrastructure.
Scalability
...
Extensible Bridging over Virtual Platforms
A tiny layer, named Virtual Platform, offers an abstract model for transparently interfacing a potentially unlimited number of hosting environments. By extending this model, new platforms can be easily integrated in the existing management facilities and new software resources added to the infrastructure. An extension is also provided to manage Web Applications on Apache Tomcat 6.x
Maven Integration
...
Coordination and Elastic Management
...

Design

Philosophy

This is the rationale behind the design. An example will be provided.

Architecture

The main software components forming the subsystem should be identified and roughly described. An architecture diagram has to be added here. A template for the representation of the architecture diagram will be proposed together with an opensource tool required to produce it.


Deployment

Usually, a subsystem consists of a number of number of components. This section describes the setting governing components deployment, e.g. the hardware components where software components are expected to be deployed. In particular, two deployment scenarios should be discussed, i.e. Large deployment and Small deployment if appropriate. If it not appropriate, one deployment diagram has to be produced.

Large deployment

A deployment diagram suggesting the deployment schema that maximizes scalability should be described here.

Small deployment

A deployment diagram suggesting the "minimal" deployment schema should be described here.

Use Cases

The subsystem has been conceived to support a number of use cases moreover it will be used to serve a number of scenarios. This area will collect these "success stories".

Well suited Use Cases

Less well suited Use Cases