Difference between revisions of "Gcube/Resource Management for the gCube Model/discussions"

Revision as of 04:15, 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:

1. a command line to execute
2. a script to execute
3. an invocation to a remote service with certain parameters

• Possible Action definition:

• 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

We discuss changes on the Resource Model according to the needs emerged on 04.05.2018

Action

TBP

Actual Virtual Service

TBP

Resource Management functionalities

Templates

• How do we create a 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.

Actions

Here we discuss the impact of the new Action resource on the Resource Management. Action is defined with formal parameters. TBP

Creating a new context After the discussion, we foresee two cases:

1. The new context is created starting from a list of Virtual Services and related actions with their actual parameters.
2. The new context is created starting from a Template and some editing of the actual parameters of the actions included in the template.