Difference between revisions of "Gcube/Resource Management for the gCube Model/discussions"
From Gcube Wiki
Manuele.simi (Talk | contribs) (→04.05.2018) |
Manuele.simi (Talk | contribs) (→04.05.2018) |
||
| Line 4: | Line 4: | ||
'''Resource Management functionalities''' | '''Resource Management functionalities''' | ||
* Merging two contexts is not a requirement | * Merging two contexts is not a requirement | ||
| − | * Cloning a context is a (new) requirement | + | * Cloning a context is a (new) requirement. We clone users, services, resources, but not data. |
* Create a template from a context to recreate it at a subsequent time (or clone it) | * Create a template from a context to recreate it at a subsequent time (or clone it) | ||
* The Resource Manager operates at Virtual Service level. A Virtual Service is a bag of Services that delivers a logical group of functionalities. A request to RM specifies which Virtual Service to add/remove/edit. The RM translates this requests to the list of concrete services and then instructs the Resource Registry accordingly. When a Service is added or removes to a context, certain configuration steps could be necessary (e.g. create a new user o space in a DBMS). | * The Resource Manager operates at Virtual Service level. A Virtual Service is a bag of Services that delivers a logical group of functionalities. A request to RM specifies which Virtual Service to add/remove/edit. The RM translates this requests to the list of concrete services and then instructs the Resource Registry accordingly. When a Service is added or removes to a context, certain configuration steps could be necessary (e.g. create a new user o space in a DBMS). | ||
Revision as of 03:59, 5 May 2018
04.05.2018
Participants: Lino, Manuele
Resource Management functionalities
- Merging two contexts is not a requirement
- Cloning a context is a (new) requirement. We clone users, services, resources, but not data.
- Create a template from a context to recreate it at a subsequent time (or clone it)
- The Resource Manager operates at Virtual Service level. A Virtual Service is a bag of Services that delivers a logical group of functionalities. A request to RM specifies which Virtual Service to add/remove/edit. The RM translates this requests to the list of concrete services and then instructs the Resource Registry accordingly. When a Service is added or removes to a context, certain configuration steps could be necessary (e.g. create a new user o space in a DBMS).
Resource Model
- Virtual Services (TPB)
- Actions to trigger associated to each Service
- Investigate if Configuration can be used
- Possible Action definition:
...
Wiki documentation
- gxRest should be linked in the Core Facilities section
- the TOC of the development guide should be a real Table of Contents. It's not possible that to find (for instance) the FWS, one has to click on sevelar links sparse on the pages (Manuele).
