Difference between revisions of "Resource Management for the gCube Model"
From Gcube Wiki
Manuele.simi (Talk | contribs) |
Manuele.simi (Talk | contribs) |
||
| Line 14: | Line 14: | ||
* managing resources within a context according to the [[Facet_Based_Resource_Model#gCube_Model|'''gCube Resource Model''']]. | * managing resources within a context according to the [[Facet_Based_Resource_Model#gCube_Model|'''gCube Resource Model''']]. | ||
| − | Contexts may have an arbitrary hierarchy. | + | Contexts may have an arbitrary hierarchy. |
== Design requirements == | == Design requirements == | ||
| Line 21: | Line 21: | ||
The Resource Management software is expected to deliver its operations by collaborating with the following components: | The Resource Management software is expected to deliver its operations by collaborating with the following components: | ||
| − | * [[Information_System_Resource_Registry | Resource Registry]] and its client libraries to add/remove/edit/merge contexts and their resources. | + | * [[Information_System_Resource_Registry | Resource Registry]] and its client libraries to add/remove/edit/merge contexts and their resources. The scope of this interaction is to make the resources discoverable in a new context (or un-discoverable if removed). |
| − | + | * [[Authorization_Framework | Authorization Framework]] | |
| − | + | * VHN Manager: to add/remove nodes from a context. | |
| − | + | ||
| − | + | once a new context is available, the hosting nodes hosting the Services belonging to the context need to be added to it. The RM has to contact the VHN Manager (docs?) to notifiy | |
| − | + | ||
| − | + | ||
It is expected that a portlet is built atop the Resource Management (and integrates with its client library) to request the operations. | It is expected that a portlet is built atop the Resource Management (and integrates with its client library) to request the operations. | ||
| Line 36: | Line 34: | ||
The service token with the identity of the Resource Manager service is obtained by the local SmartGears lib when the webapp with the service is activated by the container. | The service token with the identity of the Resource Manager service is obtained by the local SmartGears lib when the webapp with the service is activated by the container. | ||
| − | |||
=== On the deployment === | === On the deployment === | ||
| Line 43: | Line 40: | ||
* A new instance of the service can be added at any time to the set of instances already deployed without manual configuration of the new instance or changes to the configuration of the pre-existing ones. | * A new instance of the service can be added at any time to the set of instances already deployed without manual configuration of the new instance or changes to the configuration of the pre-existing ones. | ||
| + | == Context Interface == | ||
| + | |||
| + | === Create a Context === | ||
| + | This operation receives as parameter a context. | ||
| + | |||
| + | Steps to perform to create a new context: | ||
| + | * Validation: the new context must be properly framed in the pre-existing context hierarchy. For example: | ||
| + | ** its parent context must exist | ||
| + | ** there must be no other context with the same name at the same level in the hierarchy. | ||
| + | * Contact the Resource Registry to create the context. | ||
| + | * Contact the Authorization Service by mean of its client lib to create a new context token. | ||
| + | * Add the token to local node, i.e. the node on which the RM is running automatically joins the new context. | ||
| + | |||
| + | == Resource Interface == | ||
| + | |||
| + | === Add to Context === | ||
| + | |||
| + | This operation receives as parameters a list of [[Facet_Based_Resource_Model#Virtual_Service | Virtual Services]] and a context.to the context. | ||
| + | Steps to perform: | ||
| + | * Validation. The context must exist and the same Virtual Services must not be already part of the context (unless replication is allowed). | ||
| + | * Contacts the RR in order to: | ||
| + | ** navigate the parent scope(s) and select the pre-existing (already deployed) Virtual Services to add to the context (is that correct?) | ||
| + | ** add the Virtual Services to the context. With a cascade policy on the [[Facet_Based_Resource_Model#callsFor | callFor]] relation, all the [[Facet_Based_Resource_Model#Service | Services]] related to each Virtual Service are automatically added to the context by the RR. | ||
| + | ** navigate the [[Facet_Based_Resource_Model#demands | demands]] relations and discover the [[Facet_Based_Resource_Model#Software | Software(s)]] required by each Virtual Service (typically not running on SmartGears, e.g. a DBMS). Then add this Software to the new context. | ||
== Related documentation == | == Related documentation == | ||
Revision as of 22:35, 11 November 2017
This component is under development.
Role and Responsibilities
Resource Management refers to a set of software components revolving around the Resource Manager service. They are collectively responsible for delivering the following operations:
- creating contexts
- moving, editing, merging, deleting contexts
- managing resources within a context according to the gCube Resource Model.
Contexts may have an arbitrary hierarchy.
Design requirements
On the interaction with other components
The Resource Management software is expected to deliver its operations by collaborating with the following components:
- Resource Registry and its client libraries to add/remove/edit/merge contexts and their resources. The scope of this interaction is to make the resources discoverable in a new context (or un-discoverable if removed).
- Authorization Framework
- VHN Manager: to add/remove nodes from a context.
once a new context is available, the hosting nodes hosting the Services belonging to the context need to be added to it. The RM has to contact the VHN Manager (docs?) to notifiy
It is expected that a portlet is built atop the Resource Management (and integrates with its client library) to request the operations.
On the context it operates
Considering that each token is bound to a single context, while the Resource Management needs to work across contexts, the interactions with the Resource Registry have to be trusted because of the caller identity. I.e. the RR allows the Resource Management to do whatever it wants just because of its identity and regardless the context attached to the call. We would need to set up new policies for this authZ.
The service token with the identity of the Resource Manager service is obtained by the local SmartGears lib when the webapp with the service is activated by the container.
On the deployment
- The service has to be stateless. Multiple instances will be deployed behind a HAProxy.
- The service has to be able to manage more than one context (a.k.a. scope). In principle, we will deploy just one set of instances of the service (behind the proxy) to manage the infrastructure context, the VOs, and VREs. However, it should also be possible to deploy one instance for a specific VO.
- A new instance of the service can be added at any time to the set of instances already deployed without manual configuration of the new instance or changes to the configuration of the pre-existing ones.
Context Interface
Create a Context
This operation receives as parameter a context.
Steps to perform to create a new context:
- Validation: the new context must be properly framed in the pre-existing context hierarchy. For example:
- its parent context must exist
- there must be no other context with the same name at the same level in the hierarchy.
- Contact the Resource Registry to create the context.
- Contact the Authorization Service by mean of its client lib to create a new context token.
- Add the token to local node, i.e. the node on which the RM is running automatically joins the new context.
Resource Interface
Add to Context
This operation receives as parameters a list of Virtual Services and a context.to the context. Steps to perform:
- Validation. The context must exist and the same Virtual Services must not be already part of the context (unless replication is allowed).
- Contacts the RR in order to:
- navigate the parent scope(s) and select the pre-existing (already deployed) Virtual Services to add to the context (is that correct?)
- add the Virtual Services to the context. With a cascade policy on the callFor relation, all the Services related to each Virtual Service are automatically added to the context by the RR.
- navigate the demands relations and discover the Software(s) required by each Virtual Service (typically not running on SmartGears, e.g. a DBMS). Then add this Software to the new context.
