diff --git a/doc/OpenSlice_deployment_examples.md b/doc/OpenSlice_deployment_examples.md
index 1c21271e0479574aad0e62ffabf9510d9342e594..d0d98813cd5182ee738d06f4a94418d88697976e 100644
--- a/doc/OpenSlice_deployment_examples.md
+++ b/doc/OpenSlice_deployment_examples.md
@@ -1,4 +1,4 @@
-# OpenSlice deployment examples
+# OpenSlice Deployment Examples
Here are some examples from past and current efforts that use OpenSlice in various cases.
diff --git a/doc/architecture/CRIDGE/CRIDGEforDevelopers.md b/doc/architecture/CRIDGE/CRIDGEforDevelopers.md
index 07b0138edeea670eaf972709f12f7afbc9c40435..f491ee872eddbdd938499a922b5f0027a619f248 100644
--- a/doc/architecture/CRIDGE/CRIDGEforDevelopers.md
+++ b/doc/architecture/CRIDGE/CRIDGEforDevelopers.md
@@ -1,7 +1,7 @@
# CRIDGE: A Service to manage Custom Resources in a Kubernetes Cluster
-## Intended Audience: OSL developers
+**Intended Audience: OpenSlice Developers**
> Kubernetes is an orchestration system for automating software deployment, scaling, and management. One can interact though the Kubernetes API and it has a set of objects ready for use out of the box. Custom Resource Definitions (CRDs) is a way that allows to manage things other than Kubernetes itself and allows to create our own objects The use of CRDs makes the possibilities of Kubernetes management almost limitless. You can extend the base Kubernetes API with any object you like using CRDs.
diff --git a/doc/config_intro.md b/doc/config_intro.md
index c3549c1554349b33b949f361341d15cbb7bbd500..94fe71c9fa525f6c759fe4a424d1677276eb7842 100644
--- a/doc/config_intro.md
+++ b/doc/config_intro.md
@@ -1,6 +1,6 @@
# Configuring and managing OpenSlice
-## Intended Audience: OpenSlice administrators
+**Intended Audience: OpenSlice Administrators**
This section provides information on how to configure and manage different aspect of OpenSlice while in operation. For example:
diff --git a/doc/deployment.md b/doc/deployment.md
index e2a495a67146ca9f1e31d7009bb2024f0cd98734..79f8697dbdeb85e5856aecec7f620a4b36760267 100644
--- a/doc/deployment.md
+++ b/doc/deployment.md
@@ -1,8 +1,8 @@
# OpenSlice Deployment
-This section is meant to guide the user through the installation of OpenSlice.
+**Intended Audience: OpenSlice Administrators**
-## Intended Audience: OpenSlice administrators
+This section is meant to guide the user through the installation of OpenSlice.
Following, you may thorough guides depending on the installation type of your choice:
diff --git a/doc/deploymentCompose.md b/doc/deploymentCompose.md
index 913e07fab708c51f3a37e41e5408e15300576469..a2ed9a614ade138ebfd19a426fe073dde04b9aaf 100644
--- a/doc/deploymentCompose.md
+++ b/doc/deploymentCompose.md
@@ -1,6 +1,6 @@
# OpenSlice Deployment Guide with Docker Compose
-## Intended Audience: OpenSlice administrators
+**Intended Audience: OpenSlice Administrators**
## Requirements
diff --git a/doc/deploymentK8s.md b/doc/deploymentK8s.md
index e80e65a93174bdd23362037eb5ecaa76663263e5..fb00ad90bb1f43977f2b1a833da846cd8894d26b 100644
--- a/doc/deploymentK8s.md
+++ b/doc/deploymentK8s.md
@@ -1,6 +1,6 @@
# OpenSlice Deployment Guide with Kubernetes
-## Intended Audience: OpenSlice administrators
+**Intended Audience: OpenSlice Administrators**
## Requirements
diff --git a/doc/etsi_osl.md b/doc/etsi_osl.md
index 08f6df2aec3b4030475851106e731a06dfb54657..e33a2abcbeef4a3ce219427ab044d912192e38d9 100644
--- a/doc/etsi_osl.md
+++ b/doc/etsi_osl.md
@@ -1,3 +1,5 @@
-# The ETSI SDG OSL
+# OpenSlice under ETSI
-OpenSlice is developed by the OSL ETSI Software Development Group [see more info](https://osl.etsi.org/).
\ No newline at end of file
+Since October 2023, OpenSlice has been accepted under the umbrella of ETSI, forming its first Software Development Group (SDG), under the name **ETSI SDG for OpenSlice (OSL)**.
+
+More information can be found at [ETSI SDG OSL webpage](https://osl.etsi.org/).
\ No newline at end of file
diff --git a/doc/history.md b/doc/history.md
index 5608a95fe296b702489f96b385b43394226699fe..ed19a7f92178dbc0db138d2344d8bddee0e19579 100644
--- a/doc/history.md
+++ b/doc/history.md
@@ -2,8 +2,9 @@
* The NFV portal part of OpenSlice was initially developed in H2020 European Research project [5GinFIRE](https://5ginfire.eu) by University of Patras, Greece
* OpenSlice core services, APIs was further developed and maintained in H2020 European project [5G-VINNI](https://5g-vinni.eu/) by University of Patras, Greece
-* OpenSlice has been a part of OSM's OSS/BSS ecosystem
-* OpenSlice is now an ETSI SDG Group since 2023
+* OpenSlice has been a part of [OSM's OSS/BSS ecosystem](https://osm.etsi.org/wikipub/index.php/OSS_BSS)
+* OpenSlice has been a part of [ETZI ZSM PoC #2](https://zsmwiki.etsi.org/index.php?title=PoC_2_Automated_Network_Slice_Scaling_in_Multi-Site_Environments)
+* OpenSlice is the first ETSI Software Development Group (SDG) since October 2023
## Citation
diff --git a/doc/index.md b/doc/index.md
index d2f13212eab39752401ed65eac3ae4a3b8c934b9..a196cf0b2bd957a7344cf823ebe297507b1fd7ae 100644
--- a/doc/index.md
+++ b/doc/index.md
@@ -1,3 +1,6 @@
+
+# Introduction
+
<img src="images/openslice_logo.png" alt="logo" width="200"/>
**Version**: 2024Q2 - SNAPSHOT ([Release Notes](https://labs.etsi.org/rep/osl/code/org.etsi.osl.main/-/releases/2024Q2))
@@ -79,9 +82,10 @@ Login credentials:
* username=admin, password=openslice
* username=admin, password=changeme
-# Probe further
+## Probe further
-* Installing OpenSlice: See the [Deployment](deployment.md) section
+* How OpenSlice works? See the [Architecture](./architecture/architecture.md) section
+* Installing OpenSlice? See the [Deployment](deployment.md) section
* Learn more on [how OpenSlice supports Network as a Service(NaaS)](./naas/introduction.md)
-* Who is implementing OpenSlice? See [OSL ETSI SDG](https://osl.etsi.org/)
-* How OpenSlice works? See the [Architecture](./architecture/architecture.md) of OpenSlice
+* Who is maintaining OpenSlice? See [OSL ETSI SDG](https://osl.etsi.org/)
+
diff --git a/doc/naas/gst_to_tmf.md b/doc/naas/gst_to_tmf.md
index 8de472024ac206982ef938b28e86ffdf51584fe2..e1797c9ae353c4fe8c5fe41be560b03dfbe2a47e 100644
--- a/doc/naas/gst_to_tmf.md
+++ b/doc/naas/gst_to_tmf.md
@@ -1,6 +1,6 @@
# Generic Slice Template as a Service Specification
-## Intended Audience: Service Designers
+**Intended Audience: OpenSlice Service Designers**
GSMA Generic Slice Template (GST) Defines customer-oriented service requirements, E.g. Availability, Area of service, delay tolerance, etc. and attempts to narrow down the gap between (network) service customers and vendors
diff --git a/doc/naas/introduction.md b/doc/naas/introduction.md
index e986a8c77dae83bf7753a93e1179bce8afa3b32b..0a95245745e197a30b51aaa1b18fd62c91ad5416 100644
--- a/doc/naas/introduction.md
+++ b/doc/naas/introduction.md
@@ -2,13 +2,12 @@
This section describes some core concepts for Delivering Network as a Service in OpenSlice. There are many articles and reports on the subject like:
-
* TMF909 API Suite Specification for NaaS
-* TMF926A Connectivity as a Service
-* TMF931-Open Gateway Onboarding and Ordering Component Suite
-* GSMA Open Gatewy initiative
+* TMF926A Connectivity as a Service
+* GSMA Open Gateway initiative
+* TMF931 Open Gateway Onboarding and Ordering Component Suite
-In general Network as a Service (NaaS) is a service model that allows users to consume network infrastructure and services , similar to how they would consume other cloud services like Software as a Service (SaaS) or Infrastructure as a Service (IaaS). NaaS abstracts the complexity of managing physical network infrastructure, providing users with virtualized network resources that can be dynamically allocated and managed through software.
+In general Network as a Service (NaaS) is a service model that allows users to consume network infrastructure and services, similar to how they would consume other cloud services like Software as a Service (SaaS) or Infrastructure as a Service (IaaS). NaaS abstracts the complexity of managing physical network infrastructure, providing users with virtualized network resources that can be dynamically allocated and managed through software.
## OpenSlice and NaaS
diff --git a/doc/naas/lcm_intro.md b/doc/naas/lcm_intro.md
index 5670c58f2197bba6e08f015996b137f3f307842e..079bc3196d94883f173c782b43fd57c3107e851a 100644
--- a/doc/naas/lcm_intro.md
+++ b/doc/naas/lcm_intro.md
@@ -1,11 +1,9 @@
# Lifecycle Management - LCM
-
-Lifecycle Management: The orchestration framework handles the activation, termination and any necessary modifications throughout the service lifecycle.
+**Intended Audience: OpenSlice Service Designers**
-## Intended Audience: Service Designers
-
+Lifecycle Management: The orchestration framework handles the activation, termination and any necessary modifications throughout the service lifecycle.
In OpenSlice the Lifecycle of a service follows in general the concept of Network Slice lifecycle as defined by 3GPP.
diff --git a/doc/naas/lcm_rules_intro.md b/doc/naas/lcm_rules_intro.md
index f7d70588e8a9b783d071a147571db4d57183fe95..d8d73e1195d7c8a2fe5898e891314dc13484dc03 100644
--- a/doc/naas/lcm_rules_intro.md
+++ b/doc/naas/lcm_rules_intro.md
@@ -1,22 +1,20 @@
# Lifecycle Management Rules - LCM Rules
+**Intended Audience: OpenSlice Service Designers**
Lifecycle Management Rules: Defining complex conditions and actions during the lifecycle of a service and any necessary modifications throughout the service lifecycle.
+OpenSlice end-to-end (E2E) service orchestrator follows some predefined workflows to manage a service lifecycle (They are described in BPMN language and included in our orchestration engine)
-## Intended Audience: Service Designers
+So in the system there are already predefined recipes, which in each process-step of the workflow some piece of code is executed.
- OpenSlice end-to-end (E2E) service orchestrator follows some predefined workflows to manage a service lifecycle (They are described in BPMN language and included in our orchestration engine)
-
- So in the system there are already predefined recipes, which in each process-step of the workflow some piece of code is executed.
-
- How is it possible to intervene in the workflow process and inject some user defined actions? The next image illustrates the idea
+How is it possible to intervene in the workflow process and inject some user defined actions? The next image illustrates the idea
[](./lcm/img02.png)
## How is it possible to intervene in the workflow process and affect it?
-LCM Rules are used for defining complex conditions and actions during the lifecycle of a service. In Openslice there are the following types of rules defined:
+LCM Rules are used for defining complex conditions and actions during the lifecycle of a service. In OpenSlice there are the following types of rules defined:
* PRE_PROVISION
* CREATION
diff --git a/doc/naas/service_catalog.md b/doc/naas/service_catalog.md
index c29d2b0f5781149fc4ddce8512f47cde81a561c9..142c00b43c0503ff5d28f49b5e2082a3dc66c04b 100644
--- a/doc/naas/service_catalog.md
+++ b/doc/naas/service_catalog.md
@@ -1,13 +1,10 @@
# OpenSlice Service Catalogs
-OpenSlice offers complete management of Service Catalogs.
+**Intended Audience: OpenSlice Service Designers, Administrators, Users**
-## Intended Audience: Service Designers, OpenSlice administrators, Users
+OpenSlice offers complete management of Service Catalogs to end users, which comprises:
-
-OpenSlice offers complete management of Service Catalogs which offer to end users:
-
-* Service categories: Lists the available services, including their specifications and performance metrics.
+* Service Categories: Lists the available services, including their specifications and performance metrics.
* Service Bundles: Combines multiple services into a single offering to provide added value to customers.
Service Catalogs contain Service Specifications (organized in Service Categories) exposed to users for Service Orders.
@@ -15,7 +12,7 @@ Service Catalogs contain Service Specifications (organized in Service Categories
## UI management
-In the UI this looks like the following. Service catalogs and categories exposed in Service marketplace.
+The UI is built around Service Catalogs and Categories exposed in the Service Marketplace.
In the menu the administrator can manage the Service Catalogs and Categories.
diff --git a/doc/naas/service_inventory.md b/doc/naas/service_inventory.md
index f162b499292af5137873ac24baa81fcc2ac3b870..51c63a52e5cd739b313f3d691281e2ecbf733e75 100644
--- a/doc/naas/service_inventory.md
+++ b/doc/naas/service_inventory.md
@@ -1,9 +1,8 @@
# Service Inventory
-Service Inventory contains references to running services that realize a Service Order.
-
-## Intended Audience: Service Designers, OpenSlice administrators, Users
+**Intended Audience: OpenSlice Service Designers, Administrators, Users**
+Service Inventory contains references to running services that realize a Service Order.
The Service Inventory is a repository that maintains detailed records of all active services and the underlying resources that support them. It acts as a central repository, tracking the lifecycle of each service from provisioning to decommissioning, and includes references to the specific virtual and physical resources that realize the service, such as servers, network components, storage, and software instances.
diff --git a/doc/naas/service_ordering.md b/doc/naas/service_ordering.md
index 29584172298d6851fed7ad1e988880e77650bd8f..48c40d2e05c3ebacea168f05f5a2f35a250ca7a0 100644
--- a/doc/naas/service_ordering.md
+++ b/doc/naas/service_ordering.md
@@ -1,15 +1,14 @@
# Service Ordering
-Customer Facing Service Specifications - or also CFSSpec (organized in Service Categories) are exposed to users for Service Orders.
-
-## Intended Audience: Service Designers, OpenSlice administrators
+**Intended Audience: OpenSlice Service Designers, Administrators**
+Customer Facing Service Specifications - or also CFSSpec (organized in Service Categories) are exposed to users for Service Orders.
The Service Order process is a structured sequence of steps initiated by a customer's Service Order request for a specific service, aimed at delivering and activating the desired service or services (if it is a service bundle), as well as its related services. It begins with the customer submitting a service request through OpenSlice Services portal or the Service Order API, specifying the necessary details such as service specification, configurations, and any specific requirements.
The request is then validated and verified for completeness and eligibility by an administrator which marks the Service Order as ACKNOWLEDGED otherwise it rejects it.
-Once ACKNOWLEDGED, the service order is processed by OpenSlice orchestration system (OSOM), which schedules/automates the provisioning of the required resources and configurations, coordinating across various components such as MANO controlers for virtual network functions (VNFs), or Containerized controllers or any 3rd party controllers or services or even physical infrastructure. The OpenSlice orchestration system ensures that all dependencies are managed and that the service is correctly configured.
+Once ACKNOWLEDGED, the service order is processed by OpenSlice orchestration system (OSOM), which schedules/automates the provisioning of the required resources and configurations, coordinating across various components such as MANO controllers for virtual network functions (VNFs), or Containerized controllers or any 3rd party controllers or services or even physical infrastructure. The OpenSlice orchestration system ensures that all dependencies are managed and that the service is correctly configured.
After provisioning, the service is activated and handed over to the customer, . This end-to-end process ensures a seamless, efficient, and automated delivery of services, enhancing customer satisfaction and operational efficiency.
diff --git a/doc/naas/service_spec.md b/doc/naas/service_spec.md
index 983acdadf56f805170a02cf84f39f2675837870d..50a2b7449baa21d57d2a8d1654118db9252f03e2 100644
--- a/doc/naas/service_spec.md
+++ b/doc/naas/service_spec.md
@@ -1,13 +1,13 @@
# OpenSlice Service Specification
-OpenSlice offers complete management of Service Specifications.
+**Intended Audience: OpenSlice Service Designers**
-## Intended Audience: Service Designers
+OpenSlice offers complete management of Service Specifications.
Service Specification is an entity that describes a service offering. There are two types of Service Specifications:
-* Resource Facing Service Specification
-* Customer Facing Service Specification
+* Resource Facing Service Specification (RFSS)
+* Customer Facing Service Specification (CFSS)
## Resource Facing Service Specification
@@ -33,9 +33,9 @@ Usually a Service Specification has the following aspects:
Service Designers can create a Service Specification from scratch or use some templates:
- * Create a Service based from a Network Service Descriptor (NSD)
- * Create a Service based on a Kubernetes Operator
- * Create a Service based on the GSMA GST - Generic Slice Template
+* Create a Service based from a Network Service Descriptor (NSD)
+* Create a Service based on a Kubernetes Operator
+* Create a Service based on the GSMA GST - Generic Slice Template
## UI management
@@ -55,12 +55,11 @@ endpoint examples:
/serviceCatalogManagement/v4/serviceSpecification List or find ServiceSpecification objects
-
## Example Use Case
Scenario: A service provider wants to offer a new managed XXXX service to enterprise customers.
- * Service Definition: Create a service specification template for the XXXX service, including specifications for bandwidth, network features, and performance metrics.
+* Service Definition: Create a service specification template for the XXXX service, including specifications for bandwidth, network features, and performance metrics.
## Probe further
diff --git a/doc/naas/so_intro.md b/doc/naas/so_intro.md
index 7e454bc6a411afdcb4af8c49b2462961cb661637..3eac698bcb773bfce9a2e6e7f7bacc26a2e471d6 100644
--- a/doc/naas/so_intro.md
+++ b/doc/naas/so_intro.md
@@ -1,8 +1,9 @@
# Service Orchestration
-Definition: The orchestration engine evaluates the request, determines the necessary resources, and initiates the automated workflows.It interacts with underlying controller components (e.g. 5G Core, Radios, Containerized controllers, NFV, SDN controllers) to provision and configure the required network functions and connectivity.
+**Intended Audience: OpenSlice Service Designers**
+
+*Definition*: The orchestration engine evaluates the request, determines the necessary resources, and initiates the automated workflows.It interacts with underlying controller components (e.g. 5G Core, Radios, Containerized controllers, NFV, SDN controllers) to provision and configure the required network functions and connectivity.
-## Intended Audience: Service Designers
OpenSlice end-to-end (E2E) service orchestration framework is designed to manage and automate the entire lifecycle of services across multiple domains and technologies. For delivering, Network as a Service (NaaS) OpenSlice automates and manages the entire lifecycle of network services, from provisioning to monitoring and decommissioning, while ensuring seamless integration, operation, and delivery of services from the initial request to the final delivery, spanning all involved components and layers.
diff --git a/doc/role_keycloak_management.md b/doc/role_keycloak_management.md
index 153d5c312b3b30b8020097d6dd2a0346446c3e3c..a7d6a1a39bd9ee02aaf1bc38741bb50512a1e587 100644
--- a/doc/role_keycloak_management.md
+++ b/doc/role_keycloak_management.md
@@ -1,8 +1,8 @@
# Role management in Keycloak
-Some initial configuration of Keycloak happens at Installation/Deployment time. Here are some notes regarding user management
+**Intended Audience: OpenSlice Administrators**
-## Intended Audience: OpenSlice administrators
+Some initial configuration of Keycloak happens at Installation/Deployment time. Here are some notes regarding user management
There are cases that OpenSlice administrators need to configure Keycloak:
diff --git a/doc/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md b/doc/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md
index 6d9dd1525590a20b982dee72b212e0d230d5fff5..f2c0f52c71a86ee872303e0acd7e7030f213c1d0 100644
--- a/doc/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md
+++ b/doc/service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md
@@ -1,14 +1,12 @@
# Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice
-## Intended Audience: Service Designers
+**Intended Audience: OpenSlice Service Designers**
-
-> To illustrate the powerful concept of Kubernetes operators and how they can be utilized to offer a service through OpenSlice, let's provide an example of a "Calculator as a Service."
+> To illustrate the powerful concept of Kubernetes operators and how they can be utilized to offer a service through OpenSlice, let's provide an example of a "Calculator as a Service."
> This example will demonstrate the flexibility and capabilities of Kubernetes operators in managing custom resources and automating operational tasks.
-
---
## Offering "Calculator as a Service" through OpenSlice
@@ -22,8 +20,7 @@ Assume the following simple CRD of a calculator model accepting two params (spec
The controller (the calculator code) is implemented in any language and is installed in a Kubernetes cluster
-```
-
+```yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
@@ -66,7 +63,7 @@ spec:
Request to the cluster (through e.g. kubectl apply)
-```
+```yaml
apiVersion: examples.osl.etsi.org/v1alpha1
kind: MyCalculator
metadata:
@@ -75,12 +72,11 @@ spec:
parama: 170
paramb: 180
action: 'SUM'
-
```
Response
-```
+```yaml
apiVersion: examples.osl.etsi.org/v1alpha1
kind: MyCalculator
metadata:
@@ -103,7 +99,7 @@ To perform this through OpenSlice as a Service Specification ready to be ordered
---
### CRD is saved automatically as Resource Specification
-As soon as the CRD is deployed in the cluster (e.g. by your admin via kubctl or via any installation through the internet) it is automatically transformed and is available in OpenSlice catalogs as a Resource Specification.
+As soon as the CRD is deployed in the cluster (e.g. by your admin via kubectl or via any installation through the internet) it is automatically transformed and is available in OpenSlice catalogs as a Resource Specification.
- See also the fully qualified name of the resource specification.
- MyCalculator@examples.osl.etsi.org/v1alpha1@docker-desktop@https://kubernetes.docker.internal:6443/
@@ -122,9 +118,9 @@ As soon as the CRD is deployed in the cluster (e.g. by your admin via kubctl or
---
-# Expose to Users
+## Expose to Users
-## Start by Creating a ResourceFacingServiceSpecification
+### Create a ResourceFacingServiceSpecification
From the UI menu create a new Service Specification
@@ -135,19 +131,19 @@ From the UI menu create a new Service Specification
-### Creation of CRD-related characteristics
+#### Create CRD-related characteristics
- We need now to adjust some characteristics of this CRD as Resource Specification.
-- OpenSlice transalted automatically the CRD spec in a flat list of characteristics.So the "spec" section from the original yaml for example, is now unfold into: spec, spec.parama, spec.paramb, etc. the same for "status" object
-- We need to make OpenSlice aware of when the service will be active.
+- OpenSlice translated automatically the CRD spec in a flat list of characteristics.So the "spec" section from the original yaml for example, is now unfold into: spec, spec.parama, spec.paramb, etc. the same for "status" object
+- We need to make OpenSlice aware of when the service will be active.
- So we go to characteristic _CR_CHECK_FIELD and we define that the field that shows the status of the service is the characteristic "status.status" (is a text field)
- Then we go to _CR_CHECKVAL_AVAILABLE and we define the value CALCULATED, which signals the following: When the characteristic "status.status" has the value "CALCULATED" then OpenSlice will mark the underlying service as "ACTIVE"
- We need also to define the yaml file that OpenSLice will use to create the new resource in the kubernetes cluster
- We insert the YAML in the characteristic _CR_SPEC
- the _CR_SPEC is:
+The _CR_SPEC is:
-```
+```yaml
apiVersion: examples.osl.etsi.org/v1alpha1
kind: MyCalculator
metadata:
@@ -165,12 +161,12 @@ spec:
> However the values are fixed. How do we allow a user to pass parameters through OpenSlice
-## Expose in Catalog
+### Expose in Catalog
Create a new CustomerFacingServiceSpecification
- Go to the menu Service Specification>New Service Specification
- - Create a service My Calulator and mark it as a Bundle
+ - Create a service My Calculator and mark it as a Bundle
- Go to Service Specification Relationships and add MyCalculatorRFS
- The service will be automatically transformed to a "CustomerFacingServiceSpecification"
- Add the following characteristics as the image shows:
@@ -192,11 +188,8 @@ We need to Create LCM rules in CustomerFacingServiceSpecification:
-
-
If we see one rule it will look like the following:
-
- We need to change the _CR_SPEC characteristic of the referenced ResourceFacingServiceSpecification
@@ -206,7 +199,7 @@ If we see one rule it will look like the following:
- Add a block for text _CR_SPEC
- We use a block that changes a String according to variables Text>"A formatted text replacing variables from List"
- See that we have as Input string the YAML string lines
- - see that parama, paramb has a %d (they accept integers), action is %s (accepts a string)
+ - See that parama, paramb has a %d (they accept integers), action is %s (accepts a string)
- See that the variables tha will replace the %d, %d and %s are an list
- the first %d will be replaced with the value from characteristic spec.parama
- the second %d will be replaced with the value from characteristic spec.paramb
@@ -237,14 +230,12 @@ Expose it then to a catalogue for orders through the Service Categories and Serv
-### Order the Service
+## Order the Service
When a user orders the service, it will look like this:
-
-
- After the Service Order we have 2 services in service inventory on CFS and on RFS. Both have references to values
- OpenSlice (via CRIDGE service) updates the Resource in Resource Inventory and OSOM updates the Services in Service Inventory
- The Actual resources are running in the Kubernetes cluster managed by OpenSlice
@@ -256,16 +247,14 @@ When a user orders the service, it will look like this:
-### Modify the running service
+## Modify the running service
- The user can modify the service
+The user can modify the service
- 
-
+
-
- After a while the update is applied to the cluster, the controller will pick up the resource update and patch the resource
- OpenSlice (via CRIDGE service) updates the Resource in Resource Inventory and OSOM updates the Services in Service Inventory
- The result will be available to the respective characteristic "Result" after a few seconds, as need to go through various steps (OpenSlice orchestrator, down to kubernetes, to Calculator controller and back)
- 
\ No newline at end of file
+
\ No newline at end of file
diff --git a/doc/service_design/intro.md b/doc/service_design/intro.md
index d3ba61cdacab1d4f0ba837cbb228eed7bb126890..395d0258bc512a7a992fea3539dbed40906bc3e8 100644
--- a/doc/service_design/intro.md
+++ b/doc/service_design/intro.md
@@ -1,8 +1,9 @@
# Service Design in OpenSlice
-This section offers details on how to design Service Specifications and expose them in Service Catalogs
+**Intended Audience: OpenSlice Service Designers**
+
-## Intended Audience: Service Designers
+This section offers details on how to design Service Specifications and expose them in Service Catalogs
Service Designers create detailed service specifications, which are then managed and exposed in service catalogs. These services are integrated into OpenSlice E2E service orchestration framework to automate and optimize the delivery of network services.
diff --git a/doc/service_design/kubernetes/ExposingKubernetesResources.md b/doc/service_design/kubernetes/ExposingKubernetesResources.md
index e17df5f374b109c1eb95b5a22cd338025dff4a05..846032f29d8fecd112fb257d90bebf35be545a2b 100644
--- a/doc/service_design/kubernetes/ExposingKubernetesResources.md
+++ b/doc/service_design/kubernetes/ExposingKubernetesResources.md
@@ -1,9 +1,9 @@
# Expose and manage Kubernetes Custom Resource Definitions (Operators) in a Kubernetes Cluster
-OpenSlice is capable of exposing Kubernetes Resources and Definitions as Service Specifications.
+**Intended Audience: OpenSlice Service Designers**
-## Intended Audience: Service Designers
+OpenSlice is capable of exposing Kubernetes Resources and Definitions as Service Specifications.
Use OpenSlice to expose NFV resources in service catalogs and deploy them in complex scenarios (service bundles) involving also other systems:
@@ -14,11 +14,11 @@ Use OpenSlice to expose NFV resources in service catalogs and deploy them in com
> Kubernetes is an orchestration system for automating software deployment, scaling, and management. One can interact though the Kubernetes API and it has a set of objects ready for use out of the box. Custom Resource Definitions (CRDs) is a way that allows to manage things other than Kubernetes itself and allows to create our own objects The use of CRDs makes the possibilities of Kubernetes management almost limitless. You can extend the base Kubernetes API with any object you like using CRDs.
- > By allowing the design and lifecycle management of services/resources that expose CRDs/CRs in a Kubernetes cluster via the TMF APIs, OSL can be used in many complex scenarios now involing resources from multiple domains.
+ > By allowing the design and lifecycle management of services/resources that expose CRDs/CRs in a Kubernetes cluster via the TMF APIs, OpenSlice can be used in many complex scenarios now involving resources from multiple domains.
1. OpenSlice is capable to:
- - Create and manage Custom Resources (CRs) using installed CRDs on a target Kubernetes cluster.
+ - Create and manage Custom Resources (CRs) using installed CRDs on a target Kubernetes cluster.
- Facilitate complex orchestration scenarios by wrapping Kubernetes APIs as TMF APIs and models.
- Handles connectivity to a Kubernetes cluster and manages the lifecycle of CRDs
- Wraps the Kubernetes API, Receives and provides resources towards other OpenSlice services via the service bus
@@ -37,7 +37,7 @@ Use OpenSlice to expose NFV resources in service catalogs and deploy them in com
## Approach
- > OpenSlice in general is responible for exposing service specifications which are ready to be ordered and orchestrated, through tmforum Open APIs as defined in the OSL Service Spec Catalog. Usually for a service specification a corresponding (one or more) resource specification (resourceSpecificationReference) is registered in the OSL Resource Spec Catalog.
+In gerenal, OpenSlice is responsible for exposing service specifications which are ready to be ordered and orchestrated, through TMForum Open APIs as defined in the OSL Service Spec Catalog. Usually for a service specification a corresponding (one or more) resource specification (resourceSpecificationReference) is registered in the OSL Resource Spec Catalog.
The following image illustrates the approach.
@@ -45,24 +45,24 @@ The following image illustrates the approach.
1. A CRD in a cluster will be mapped in TMF model as a Resource specification and therefore can be exposed as a service specification in a catalog
-2. Service Orders can be created for this service specification.
+2. Service Orders can be created for this service specification.
3. OSOM creates a Resource in OSL Resource inventory and requests new Custom Resource (CR) in the target cluster
- The resource is created in a specific namespace (for example the UUID of the Service Order)
- A CR in a cluster will be mapped in TMF model as a Resource in the resource Inventory
- Other related resources created by the CRD Controller within the namespace are automatically created in OSL Resource Inventory under the same Service Order
-## Awareness for CRDs and CRs in cluster
+## Awareness for CRDs and CRs in cluster
> CRDs and CRs can appear (disappear) or change status at any time in a cluster. OpenSlice Resource Inventory need to be aware of these events.
- When installing OpenSlice you can configure at least one management cluster. OpenSlice connects via a provided kubeconf
+When installing OpenSlice you can configure at least one management cluster. OpenSlice connects via a provided kubeconf
-- On Start up OSL tries to register this cluster and context to OSL catalogs.
+- On start-up, OSL tries to register this cluster and context to OSL catalogs.
- After the registration of this cluster as a Resource in OSL OSL is always aware of all CRDs and their CRs in the cluster, even if a CRD or CR is added/updated/deleted in the K8S cluster outside of OSL
- Resources created by OpenSlice have labels, e.g. (org.etsi.osl.*)
-## Expose CRDs as Service Specifications in OpenSlice catalogs
+## Expose CRDs as Service Specifications in OpenSlice catalogs
**A CRD by default is exposed as a Resource Specification**
@@ -72,63 +72,68 @@ To ensure unique names across the clusters that OpenSlice can manage, the name o
For example you might see resource Specifications like:
- - ```Application@argoproj.io/v1alpha1@kubernetes@https://10.10.10.144:6443/```
- - ```IPAddressPool@metallb.io/v1beta1@kubernetes@https://10.10.10.144:6443/```
- - ```Provider@pkg.crossplane.io/v1@kubernetes@https://10.10.10.144:6443/```
+- Application@argoproj.io/v1alpha1@kubernetes@https://10.10.10.144:6443/```
+- ```IPAddressPool@metallb.io/v1beta1@kubernetes@https://10.10.10.144:6443/```
+- ```Provider@pkg.crossplane.io/v1@kubernetes@https://10.10.10.144:6443/```
All attributes of the CRD are translated into characteristics
The following specific characteristics are **added**:
- - _CR_SPEC: Used for providing the json Custom Resource description to apply
- - _CR_CHECK_FIELD: Used for providing the field that need to be checked for the resource status
- - _CR_CHECKVAL_STANDBY: Used for providing the equivalent value from resource to signal the standby status
- - _CR_CHECKVAL_ALARM: Used for providing the equivalent value from resource to signal the alarm status
- - _CR_CHECKVAL_AVAILABLE: Used for providing the equivalent value from resource to signal the available status
- - _CR_CHECKVAL_RESERVED: Used for providing the equivalent value from resource to signal the reserved status
- - _CR_CHECKVAL_UNKNOWN: Used for providing the equivalent value from resource to signal the unknown status
- - _CR_CHECKVAL_SUSPENDED: Used for providing the equivalent value from resource to signal the suspended status
-
+```yaml
+- _CR_SPEC: Used for providing the json Custom Resource description to apply
+- _CR_CHECK_FIELD: Used for providing the field that need to be checked for the resource status
+- _CR_CHECKVAL_STANDBY: Used for providing the equivalent value from resource to signal the standby status
+- _CR_CHECKVAL_ALARM: Used for providing the equivalent value from resource to signal the alarm status
+- _CR_CHECKVAL_AVAILABLE: Used for providing the equivalent value from resource to signal the available status
+- _CR_CHECKVAL_RESERVED: Used for providing the equivalent value from resource to signal the reserved status
+- _CR_CHECKVAL_UNKNOWN: Used for providing the equivalent value from resource to signal the unknown status
+- _CR_CHECKVAL_SUSPENDED: Used for providing the equivalent value from resource to signal the suspended status
+```
1. Create a new Service Specification and use this Resource Specification in Resource Specification Relationships
- Then the Service Specification is saved as ResourceFacingServiceSpecification
- 1.1. You can give at this stage values to the characteristics:
+ 1.1. At this stage, you can give values to the characteristics:
- - _CR_SPEC,
- - _CR_CHECK_FIELD
- - _CR_CHECKVAL_STANDBY
- - _CR_CHECKVAL_ALARM
- - _CR_CHECKVAL_AVAILABLE
- - _CR_CHECKVAL_RESERVED
- - _CR_CHECKVAL_UNKNOWN
- - _CR_CHECKVAL_SUSPENDED
-
+ ```
+ - _CR_SPEC,
+ - _CR_CHECK_FIELD
+ - _CR_CHECKVAL_STANDBY
+ - _CR_CHECKVAL_ALARM
+ - _CR_CHECKVAL_AVAILABLE
+ - _CR_CHECKVAL_RESERVED
+ - _CR_CHECKVAL_UNKNOWN
+ - _CR_CHECKVAL_SUSPENDED
+ ```
+
1.2. You can now create LCM rules if you wish
2. Create a new Service Specification and use the Resource Facing Service Specification in Service Specification Relationships
- Then the Service Specification is saved as CustomerFacingServiceSpecification
- 2.1. You can give at this stage values to the characteristics:
+ 2.1. At this stage, you can give values to the characteristics:
- - _CR_SPEC,
- - _CR_CHECK_FIELD
- - _CR_CHECKVAL_STANDBY
- - _CR_CHECKVAL_ALARM
- - _CR_CHECKVAL_AVAILABLE
- - _CR_CHECKVAL_RESERVED
- - _CR_CHECKVAL_UNKNOWN
- - _CR_CHECKVAL_SUSPENDED
+ ```
+ - _CR_SPEC,
+ - _CR_CHECK_FIELD
+ - _CR_CHECKVAL_STANDBY
+ - _CR_CHECKVAL_ALARM
+ - _CR_CHECKVAL_AVAILABLE
+ - _CR_CHECKVAL_RESERVED
+ - _CR_CHECKVAL_UNKNOWN
+ - _CR_CHECKVAL_SUSPENDED
+ ```
- 2.2. You We can create LCM rules for this new Service Specification
+ 2.2. You can create LCM rules for this new Service Specification
- 2.3. You Expose configurable values for users to configure during service order
+ 2.3. You can expose configurable values for users to configure during service order
## Service Orchestration and CRDs/CRs
-OSOM - OpenSlice Service Orchestrator, checks the presence of attribute _CR_SPEC at the RFS to make a request for a CR deployment
+OSOM - OpenSlice Service Orchestrator, checks the presence of attribute _CR_SPEC at the RFS to make a request for a CR deployment.
- _CR_SPEC is a JSON or YAML string that is used for the request
- It is similar to what one will do with e.g. a kubectl apply
@@ -141,18 +146,20 @@ OSOM - OpenSlice Service Orchestrator, checks the presence of attribute _CR_SPEC
OpenSlice adds automatically as we see the following characteristics:
- - _CR_CHECK_FIELD
- - _CR_CHECKVAL_STANDBY
- - _CR_CHECKVAL_ALARM
- - _CR_CHECKVAL_AVAILABLE
- - _CR_CHECKVAL_RESERVED
- - _CR_CHECKVAL_UNKNOWN
- - _CR_CHECKVAL_SUSPENDED
-
+```
+- _CR_CHECK_FIELD
+- _CR_CHECKVAL_STANDBY
+- _CR_CHECKVAL_ALARM
+- _CR_CHECKVAL_AVAILABLE
+- _CR_CHECKVAL_RESERVED
+- _CR_CHECKVAL_UNKNOWN
+- _CR_CHECKVAL_SUSPENDED
+```
+
**These characteristics instrument OpenSlice services to manage and reflect the lifecycle of a kubernetes resource to OpenSlice's (TMF based) lifecycle**
-- _CR_CHECK_FIELD: The name of the field that is needed to be monitored in order to monitor the status of the service and translate it to TMF resource statys (RESERVED AVAILABLE, etc)
+- _CR_CHECK_FIELD: The name of the field that is needed to be monitored in order to monitor the status of the service and translate it to TMF resource status (RESERVED AVAILABLE, etc)
- _CR_CHECKVAL_STANDBY: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state STANDBY (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- _CR_CHECKVAL_ALARM: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state ALARMS (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
- _CR_CHECKVAL_AVAILABLE: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state AVAILABLE (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
@@ -161,11 +168,8 @@ OpenSlice adds automatically as we see the following characteristics:
- _CR_CHECKVAL_SUSPENDED: The CR specific value (of the CheckFieldName) that needs to me mapped to the TMF resource state SUSPENDED (see org.etsi.osl.tmf.ri639.model.ResourceStatusType)
----
-
## Probe further
-
- See examples of exposing Kubernetes Operators as a Service via OpenSlice:
- [Offering "Calculator as a Service"](../examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md)
- [Offering "Helm installation as a Service" (Jenkins example)](../examples/helmInstallation_aaS_Example_Jenkins/HELM_Installation_aaS_Jenkins_Example.md)
diff --git a/doc/service_design/kubernetes/helm/design_helmaas.md b/doc/service_design/kubernetes/helm/design_helmaas.md
index ba69891b7d7c50086bf27b0307818056eacb60dc..23271e92ad760e30c6d7219893125d8fd6e14128 100644
--- a/doc/service_design/kubernetes/helm/design_helmaas.md
+++ b/doc/service_design/kubernetes/helm/design_helmaas.md
@@ -1,32 +1,34 @@
# Expose HELM charts as Service Specifications
-Manage Helm charts installations via OpenSlice Service Specifications and Service Orders.
-## Intended Audience: Service Designers
+**Intended Audience: OpenSlice ervice Designers**
-> Kubernetes is an orchestration system for automating software deployment, scaling, and management. One can interact though the Kubernetes API and it has a set of objects ready for use out of the box.
+This section introduces ways to manage Helm charts installations via OpenSlice Service Specifications and Service Orders.
-> Helm is a tool that automates the creation, packaging, configuration, and deployment of Kubernetes applications by combining your configuration files into a single reusable package
+## Kubernetes and Helm Introduction
-> At the heart of Helm is the packaging format called charts. Each chart comprises one or more Kubernetes manifests -- and a given chart can have child charts and dependent charts, as well. Using Helm charts:
+Kubernetes is an orchestration system for automating software deployment, scaling, and management. One can interact though the Kubernetes API and it has a set of objects ready for use out of the box.
-> - Reduces the complexity of deploying Microservices
-> - Enhances deployment speed
-> - Developers already know the technology
+Helm is a tool that automates the creation, packaging, configuration, and deployment of Kubernetes applications by combining your configuration files into a single reusable package
-> There are many Helm charts and Helm repositories there that are ready to be used
+At the heart of Helm is the packaging format called charts. Each chart comprises one or more Kubernetes manifests -- and a given chart can have child charts and dependent charts, as well. Using Helm charts:
-> Enable loose coupling and more orchestration scenarios
+- Reduces the complexity of deploying Microservices
+- Enhances deployment speed
+- Developers already know the technology
-> Developers create and deploy applications in things they already know (e.g. Helm charts)
+Below the core advantages in using Helms with OpenSlice are presented:
-> Use the TMF models as wrapper entities around Helm charts
+- There are many Helm charts and Helm repositories there that are ready to be used
+- Enable loose coupling and more orchestration scenarios
+- Developers create and deploy applications in things they already know (e.g. Helm charts)
+- Usage of the TMF models as wrapper entities around Helm charts
-Use OpenSlice to expose them in service catalogs and deploy them in complex scenarios (service bundles) involving also other systems:
+Also, OpenSlice can expose them in service catalogs and deploy them in complex scenarios (Service Bundles) involving also other systems:
- - Include e.g. RAN controllers,
- - Pass values through life cycle rules from one service to another,
- - Manage multiple Helms in multiple clusters
+- Include e.g. RAN controllers,
+- Pass values through life cycle rules from one service to another,
+- Manage multiple Helms in multiple clusters
## The installation of HELM charts is based on OpenSlice CRD support
@@ -34,7 +36,7 @@ Use OpenSlice to expose them in service catalogs and deploy them in complex scen
Please read more [here](../ExposingKubernetesResources.md).
-For installing HELM charts we will use ArgoCD a well known Kubernetes-native continuous deployment (CD) tool
+For installing HELM charts we will use ArgoCD a well known Kubernetes-native continuous deployment (CD) tool.
> ArgoCD is a Kubernetes-native continuous deployment (CD) tool
@@ -45,8 +47,6 @@ For installing HELM charts we will use ArgoCD a well known Kubernetes-native con
We will mainly use the CRD of ```Kind: Application``` that ArgoCD can manage
-
-
Before proceeding, install ArgoCD in your management cluster, by following ArgoCD instructions
As soon as you install ArgoCD, OpenSlice is automatically aware for specific new Kinds. The one we will use is is the ```Kind: Application``` that ArgoCD can manage under the apiGroup argoproj.io
@@ -59,9 +59,6 @@ see image:
-
-
## Probe further
-
See the [Example: Offer Jenkins as a Service via OpenSlice](../../examples/helmInstallation_aaS_Example_Jenkins/HELM_Installation_aaS_Jenkins_Example.md)
diff --git a/doc/service_design/lcmrules/intro.md b/doc/service_design/lcmrules/intro.md
index 0fb4cf473803391d7faceef8ad98581637fa5e5f..72b50ee4347bd6b86f49095dd2017b9764b7488a 100644
--- a/doc/service_design/lcmrules/intro.md
+++ b/doc/service_design/lcmrules/intro.md
@@ -1,18 +1,16 @@
# LCM Rules introduction
+**Intended Audience: OpenSlice Service Designers**
Lifecycle Management Rules: Defining complex conditions and actions during the lifecycle of a service and any necessary modifications throughout the service lifecycle.
-
-## Intended Audience: Service Designers
-
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.
-LCM Rules are used for defining complex conditions and actions during the lifecycle of a service. In Openslice there are four types of rules defined:
+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:
* PRE_PROVISION
* CREATION
@@ -25,28 +23,26 @@ The following figure displays the different phases that the rules are performed,
[](./images/lcm/lcmfig1.png)
-* 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
-
-In general the rules allow to perform many actions during service LCM. Thes are some examples:
+* 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.
-* 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)
+In general the rules allow to perform many actions during service LCM. Below, there are some examples:
+* 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).
+## Examine if the rules are executed successfully
-## Examine if the rules are executed successfully
-
-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 logfiles and also tey are attached as Notes to the running Service.
+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.
## LCM Rules and OSOM Service Orchestration
@@ -57,7 +53,7 @@ OSOM is the responsible service for executing the rules on a specific phase. The
-## Define rules
+## Define Rules
Rules are defined when designing a Service Spec. Here is an example of a list of rules:
@@ -66,7 +62,7 @@ Rules are defined when designing a Service Spec. Here is an example of a list of
Execution order of rules on a specific phase is random
-* 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.
+> 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.
### Definition language
@@ -82,13 +78,11 @@ The following figure is an example of such a rule design. The rule for example w
* On the right side the user can define some rule properties or observe the underlying generated java code.
-## The blocks library
+## The Blocks Library
See our [LCM Blocks specification](./specification.md)
-
-
## Probe further
* Check our [examples](./examples.md) for more usages
diff --git a/doc/service_design/lcmrules/specification.md b/doc/service_design/lcmrules/specification.md
index b89323f14dbf1551c403df86a7b38efb0e0cbb3c..dc79c532cba01ad8538113abb6c35175b505da31 100644
--- a/doc/service_design/lcmrules/specification.md
+++ b/doc/service_design/lcmrules/specification.md
@@ -1,14 +1,13 @@
-# LCM Blocks specification
+# LCM Blocks Specification
-
-## Intended Audience: Service Designers
+**Intended Audience: OpenSlice Service Designers**
The following images describe some blocks found in the library.
Blockly has syntax rules. It helps with colours to define them.
-So for example a parameter that is a Number cannot be "glued" with a String. Will need some conversion first
+So for example a parameter that is a Number cannot be combined with a String. Will need some conversion first
[](./images/lcm/lcmfig4.png)
[](./images/lcm/lcmfig5.png)
diff --git a/doc/service_design/nfv/design_nfv_services.md b/doc/service_design/nfv/design_nfv_services.md
index 9c0cc8e6ad0da530aa00672f3f23ce5243c22aca..9d9587a399072bfb2648e6ad675af558a43c7127 100644
--- a/doc/service_design/nfv/design_nfv_services.md
+++ b/doc/service_design/nfv/design_nfv_services.md
@@ -1,8 +1,8 @@
# Design NFV services
-OpenSlice is capable of exposing NFV-related resources (VNFs/NSDs) as Service Specifications.
+**Intended Audience: OpenSlice Service Designers**
-## Intended Audience: Service Designers
+OpenSlice is capable of exposing NFV-related resources (VNFs/NSDs) as Service Specifications.
Use OpenSlice to expose NFV resources in service catalogs and deploy them in complex scenarios (service bundles) involving also other systems:
diff --git a/doc/service_ordering/ordering_services.md b/doc/service_ordering/ordering_services.md
index 4041aa09440367caf7e861ba5dfc18c4c91d91f0..c88edca3e4f5f42a7bd560b66722a8bffed78876 100644
--- a/doc/service_ordering/ordering_services.md
+++ b/doc/service_ordering/ordering_services.md
@@ -1,5 +1,5 @@
# Service Ordering
-## Intended Audience: Users
+**Intended Audience: OpenSlice Users**
_This section is WIP._
\ No newline at end of file