Gcube/Resource Management for the gCube Model/discussions

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:

Action

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

Following up the needs emerged on 04.05.2018, we discuss changes on the Resource Model.

Action

• 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, a resource is one of the following: Software, Service, Dataset, Actor, Action.
• 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 facet is also not suitable.

TBP

Actual Virtual Service

Actual Virtual Service is a new entity in the Resource Model. It is composed by:

• 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. TBP

Resource Management functionalities

Templates

• How do we create a context template?

1. Starting from an existing context
2. 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 (TODO). RM has to remain 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 (then, from the list of its Actual Virtual Services) and some editing of the actual parameters of the actions included in the template.