View source for Gcube/Resource Management for the gCube Model/discussions


<!-- CATEGORIES --> 
<!-- [[Category: gCube Features]] -->
<!-- CATEGORIES -->
{| align="right"
||__TOC__
|}

== 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 [[Facet_Based_Resource_Model#Virtual_Service | 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.

===gCube 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 [[Facet_Based_Resource_Model#gCube_Model|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:
{| class="wikitable"
|+ Action
|-
! Trigger
| ADD || REMOVE
|-
! Executable 
| Bash Script || Command line || Remote call
|-
! Parameters
| List of params for the executable

|}
*'''TODO''': Investigate if the [[Facet_Based_Resource_Model#Configuration|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 [[Gcube/Resource_Management_for_the_gCube_Model/discussions#04.05.2018 | 04.05.2018]], we discuss changes on the gCube Resource Model. 

'''Action'''

We started the discussion on how to model Actions.
* Using [[Facet_Based_Resource_Model#PropagationConstraint | 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 [[Facet_Based_Resource_Model#Configuration | 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 [[Facet_Based_Resource_Model#Facet | 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.