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) |
||
Line 51: | Line 51: | ||
* gxRest should be linked in the Core Facilities section | * 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). | * 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 | ||
+ | |||
+ | ===Resource Model=== | ||
+ | '''Action''' | ||
+ | ... | ||
+ | '''Actual Virtual Service''' | ||
+ | ... | ||
+ | |||
+ | ===Resource Management functionalities=== | ||
+ | '''Templates''' | ||
+ | |||
+ | * How do we create context template? | ||
+ | ** Starting from an existing context | ||
+ | ** Or 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. RM has to be stateless. | ||
+ | * What format has a template definition? A list of Actual Virtual Services (see next section) | ||
+ | |||
+ | |||
+ | '''Actions''' | ||
+ | |||
+ | Here we discuss the impact of the new Action resource on the Resource Management. | ||
+ | Action is defined with formal parameters. | ||
+ | |||
+ | |||
+ | |||
+ | '''Creating a new context''' | ||
+ | After the 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 Template and some editing of the actual parameters of the actions included in the template. |
Revision as of 05:11, 9 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
Resource Model
Action ... Actual Virtual Service ...
Resource Management functionalities
Templates
- How do we create context template?
- Starting from an existing context
- Or 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. RM has to be stateless.
- What format has a template definition? A list of Actual Virtual Services (see next section)
Actions
Here we discuss the impact of the new Action resource on the Resource Management. Action is defined with formal parameters.
Creating a new context After the 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 Template and some editing of the actual parameters of the actions included in the template.