Skip to content
Snippets Groups Projects
intro.md 3.77 KiB
Newer Older
Christos Tranoris's avatar
Christos Tranoris committed
# LCM Rules introduction

trantzas's avatar
trantzas committed
**Intended Audience: OpenSlice Service Designers**
Christos Tranoris's avatar
Christos Tranoris committed

Lifecycle Management Rules: Defining complex conditions and actions during the lifecycle of a service and any necessary modifications throughout the service lifecycle.

In [Naas LCM Introduction](../../naas/lcm_intro.md) it was presented briefly the LCM Rules concept.

This section goes deeply on how Service Designers can use them.

Silvia Almagia's avatar
Silvia Almagia committed


trantzas's avatar
trantzas committed
LCM Rules are used for defining complex conditions and actions during the lifecycle of a service. In Openslice, there are five types of rules defined:
Silvia Almagia's avatar
Silvia Almagia committed

* PRE_PROVISION
* CREATION
* AFTER_ACTIVATION 
* SUPERVISION 
* AFTER_DEACTIVATION 


The following figure displays the different phases that the rules are performed, during the lifecycle of a Network Slice Instance.

![Rules in NSI](./images/lcm/lcmfig1.png)
Silvia Almagia's avatar
Silvia Almagia committed

trantzas's avatar
trantzas committed
* PRE_PROVISION rules: Run only once just before creating a service with a given priority.
* CREATION rules: Run while the referenced service dependencies of a service are created.
* AFTER_ACTIVATION rules: Run only once just after a service get the ACTIVE state.
* SUPERVISION rules: Run when a characteristic of a service is changed and the service is in the ACTIVE state.
* AFTER_DEACTIVATION rules: Run only once just after a service get the INACTIVE/TERMINATED state.
Silvia Almagia's avatar
Silvia Almagia committed

trantzas's avatar
trantzas committed
In general the rules allow to perform many actions during service LCM. Below, there are some examples:
Silvia Almagia's avatar
Silvia Almagia committed

trantzas's avatar
trantzas committed
* Modify service specification parameters before the instantiation of a service (or during operation) based on other dependencies. These parameters might be part of other services already included in Service order.
* Translate GST/NEST parameter values to other values passed later to NFVO for instantiation or control.
* Define complex OSM Configs based on other dependencies and passing variables.
* Define any dependencies when creating the referenced services.
* Dynamically include new service dependencies.
* Create new service orders so include dynamically other services.
* Call external (RESTful) services (via http(s), define payload, examine response).
Silvia Almagia's avatar
Silvia Almagia committed


trantzas's avatar
trantzas committed
## Examine if the rules are executed successfully
Silvia Almagia's avatar
Silvia Almagia committed

trantzas's avatar
trantzas committed
Rules are transformed automatically to executable code (currently is Java). If a rule is performed successfully  or has any issues (e.g. unexpected syntax errors or exceptions) appear in OSOM log files and also tey are attached as Notes to the running Service.
Silvia Almagia's avatar
Silvia Almagia committed

## LCM Rules and OSOM Service Orchestration

OSOM is the responsible service for executing the rules on a specific phase. The following image explains the design in the BPMN phases:


![Rules](./images/lcm/lcmfig1_osom.png)
Silvia Almagia's avatar
Silvia Almagia committed


trantzas's avatar
trantzas committed
## Define Rules
Silvia Almagia's avatar
Silvia Almagia committed

Rules are defined when designing a Service Spec. Here is an example of a list of rules:


![lcmrules](./images/lcm/lcmfig2.png)
Silvia Almagia's avatar
Silvia Almagia committed

Execution order of rules on a specific phase is random

trantzas's avatar
trantzas committed
> NOTE: There is a priority field. The lower the number the highest the priority of rule execution. For example Rule with priority 0 will run before rule with priority 1.
Silvia Almagia's avatar
Silvia Almagia committed


### Definition language

* The visual language that Openslice used is based on Google's Blockly (see https://developers.google.com/blockly)
* The blockly graph is automatically translated to Java internally and then dynamically executed during orchestration phases.

The following figure is an example of such a rule design. The rule for example will run in PRE_PROVISION phase:

![lcmrules](./images/lcm/lcmfig3.png)
Silvia Almagia's avatar
Silvia Almagia committed

* The goal of the above rule is to properly define a variable AreaCodes given the chosen AreaOfService from a Service Order.
* On the right side the user can define some rule properties or observe the underlying generated java code.


trantzas's avatar
trantzas committed
## The Blocks Library
Silvia Almagia's avatar
Silvia Almagia committed

Christos Tranoris's avatar
Christos Tranoris committed
See our [LCM Blocks specification](./specification.md)
Silvia Almagia's avatar
Silvia Almagia committed


Christos Tranoris's avatar
Christos Tranoris committed
## Probe further
Silvia Almagia's avatar
Silvia Almagia committed

* Check our [examples](./examples.md) for more usages
* See next the complete [Specification](./specification.md)