Difference between revisions of "Gcube/Resource Management for the gCube Model/discussions"
From Gcube Wiki
Manuele.simi (Talk | contribs) (→Resource Model) |
Manuele.simi (Talk | contribs) (→Resource Management functionalities) |
||
| Line 109: | Line 109: | ||
# By editing an existing template and saving it as new template | # By editing an existing template and saving it as new template | ||
* Where do we store the Context Template? We need a persistent layer in the Resource Management. First idea is a DBMS, but investigation is needed ('''TODO'''). RM has to remain stateless. | * Where do we store the Context Template? We need a persistent layer in the Resource Management. First idea is a DBMS, but investigation is needed ('''TODO'''). RM has to remain stateless. | ||
| − | |||
'''Actions''' | '''Actions''' | ||
| Line 117: | Line 116: | ||
* The Resource Manager must be able to execute Actions. E.g. if the ansible script requires access to an ansible playbook stored somewhere, the resource manager must be granted access to the storage. | * The Resource Manager must be able to execute Actions. E.g. if the ansible script requires access to an ansible playbook stored somewhere, the resource manager must be granted access to the storage. | ||
* List of Actions and their actual parameters (values) are received along within the request to add/remove a Virtual Service to/from a context. | * List of Actions and their actual parameters (values) are received along within the request to add/remove a Virtual Service to/from a context. | ||
| − | |||
'''Creating a new context''' | '''Creating a new context''' | ||
| − | * After | + | * After some discussion, we foresee two cases: |
# The new context is created starting from a list of Virtual Services and related actions with their actual parameters. | # The new context is created starting from a list of Virtual Services and related actions with their actual parameters. | ||
# The new context is created starting from a previously stored Template (then, from the list of its Actual Virtual Services) and some editing of the actual parameters of the actions included in the template. | # The new context is created starting from a previously stored Template (then, from the list of its Actual Virtual Services) and some editing of the actual parameters of the actions included in the template. | ||
Revision as of 04:45, 10 May 2018
04.05.2018
Participants: Lino, Manuele
Resource Management functionalities
- Discarded functionality: Merging two contexts is not a requirement
- New functionality: Cloning a context. We clone users, services, resources, but not data.
- New functionality: Create a template definition from an existing context to recreate (or clone) it at a later time
- Impact on the design: RM needs a new collection of resources Templates (in the REST sense) to operate on templates of contexts.
- Cloning a context could be an operation on a Template resource.
- 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 request to the list of concrete services (by querying the Resource Registry) and then instructs the Resource Registry accordingly.
- New functionality: When a Service is added or remove to a context (as part of a Virtual Service), certain configuration steps could be necessary (e.g. create a new user o space in a DBMS). See Actions in the following.
Resource Model
- Virtual Services: their definitions are created with a portlet
- Often, the same Virtual Service differs from one VRE to another, only for 1 Service (typically a DBMS). In these cases, we would like to have a single Virtual Service definition, not many with just a slight difference
- Possible solution: Associate also a Type to a service, define the Virtual Service to include a service of that Type, and let the RM discovers the service of that Type in the parent context of the target context.
- TODO: Investigate if Type (or similar information) already exists in the gCube Resource Model
- Actions Actions are steps to perform whenever there is a change in the participation of a service into a context. Actions are triggered by the Resource Manager when operating with the Service.
- On the resource model we need something like Service ---triggers---> Actions
- An action could be:
- a command line to execute
- a script to execute
- an invocation to a remote service with certain parameters
- Possible Action definition:
| Trigger | ADD | REMOVE | |
|---|---|---|---|
| Executable | Bash Script | Command line | Remote call |
| Parameters | List of params for the executable |
- TODO: Investigate if the Configuration facet can be used to define Actions
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 several links sparse on the pages (Manuele).
08.05.2018
Participants: Lino, Manuele
gCube Resource Model
Following up the needs emerged on 04.05.2018, we discuss changes on the gCube Resource Model.
Action
We started the discussion on how to model Actions.
- Using Propagation Constraints to define Actions does not seem appropriate since their scope and role are completely different (used by the IS to propagate add/remove to/from contexts). The Configuration resource is also not suitable.
- Action is a first-level resource to introduce in the gCube Resource Model. All the resources can have associated a list of actions to trigger.
Resource ---triggers---> Action
- At this point, the first-level resources are:
- Software
- Service
- Dataset
- Actor
- Action
Use cases:
- Typically actions are related to the persistence of a service in a Software. E.g. each Tabman instance writes in a DB hosted on the same DBMS. The Virtual Service of Tabman should trigger an action with the database name (as formal parameter) to create the database.
- Actions can potentially be considered also for deploying new services with an ansible script.
An Action is modeled with 1 or N Facets.
- One would probably hold sensitive data for accessing databases, ansible repos and similar. Sensitive facets are decrypted with symmetric keys.
Actual Virtual Service
Actual Virtual Service is a new resource in the Resource Model. It models an instantiated Virtual Service, i.e. all it was needed to add the Virtual Service to a context.
Why do we need this new resource? We identify at least three (similar) use cases:
- When we delete a context and we want to save a Template of it for recreating it in the future
- When we clone a context
- When we need to create a context slightly similar to another (existing) one
All these cases requires to save the conditions on which one or more Virtual Services have been instantiate for a second instantiation.
An Actual Virtual Service keeps the following information in its facets:
- a relation with the source Virtual Service from which it was instantiated
- a list of service instances (e.g.: Tabman running on host:port), we can use e-service
- a list of software
- a list of actions with actual parameters
Note from Manuele: in spite of what we said during the discussion, an Actual Virtual Service should not be an extension/specialization of Virtual Services because it cannot have actions, it does not inherit their relations (but it does navigate them), and ultimately it cannot be used in place of a Virtual Service.
TODO: Luca to investigate the feasibility of these extensions. Make an implementation plan for gcube-resources lib.
Resource Management functionalities
Context Templates
- What format has a Context Template definition? A list of Actual Virtual Services.
- How do we create a Context Template?
- Starting from an existing context
- By editing an existing template and saving it as new template
- Where do we store the Context Template? We need a persistent layer in the Resource Management. First idea is a DBMS, but investigation is needed (TODO). RM has to remain stateless.
Actions
Here we discuss the impact of the new Action resource on the Resource Management.
- An Action is defined by the executable and a list of formal parameters.
- The Resource Manager must be able to execute Actions. E.g. if the ansible script requires access to an ansible playbook stored somewhere, the resource manager must be granted access to the storage.
- List of Actions and their actual parameters (values) are received along within the request to add/remove a Virtual Service to/from a context.
Creating a new context
- After some discussion, we foresee two cases:
- The new context is created starting from a list of Virtual Services and related actions with their actual parameters.
- The new context is created starting from a previously stored Template (then, from the list of its Actual Virtual Services) and some editing of the actual parameters of the actions included in the template.
