Merge branch 'develop'

doc/addons/camara/intro.md

+
+# CAMARAaaS Addon
+
+## Introduction
+
+The **CAMARA as a Service (CAMARAaaS) OSL Add-on** is a prototype service developed by OSL and allows users of OSL to expose CAMARA APIs for their TMF-based services. By doing so, it enables runtime operations, such as enforcing profiles on User Equipment (UEs) or updating 5G Network Slice characteristics, using standardized CAMARA API endpoints. The work is in progress for future enhancements (e.g. multi-tenancy, etc). 
+
+In a nutshell, CAMARAaaS add-on performs API transformations from CAMARA API model to TMF API model and vice-versa.
+
+The supporting use case is the following:
+
+- An OSL Service Provider (e.g. an Operator) has a running 5G Core (e.g. from another service order in OSL).
+- The running service exposes already some characteristics (i.e. via TMF Service Inventory) that can be configured. Thus, someone can reconfigure the latter during runtime (e.g. change the quality of a slice via a TMF API service request).
+- On a subsequent step, the Service Provider makes a Service Order in OSL to expose this running 5G Core service via a CAMARA API endpoint.
+- The CAMARAaaS add-on is a wrapper between the CAMARA requests and the TMF API Service Inventory models. These CAMARA APIs will then be used to control the lifecycle and the operations that shall take place in an already existing OSL Service.
+
+Therefore, these are the key features of this add-on:
+
+- **Seamless Integration**: Operators can expose their existing OSL Services through CAMARA APIs, maintaining consistency with the OSL framework while offering additional accessibility.
+- **Dynamic Service Control**: Allows runtime updates to characteristics of 5G-related Services, such as UE profiles or Network Slices, via CAMARA REST API calls. The updated characteristics of a Service can then be consumed by a Kubernetes Custom Resource that will produce an operation according to the updated characteristics.
+
+## Architectural Approach and Service Interactions
+
+The add-on introduces a generic **CAMARA API Service**, which acts as a wrapper for existing (running) services registered in TMF Service Inventory. The architecture ensures:
+
+1. **API Exposure**: CAMARA APIs are orchestrated by OSL (offered as-a-service) and their endpoints are exposed to the end-users (clients).
+2. **Service Mapping**: The CAMARA API Service references a running service (identified by a unique UUID), enabling targeted operations. The invoking of CAMARA API endpoints will result in updates in the running service’s characteristics.
+3. **Operational Flow**: Updates triggered via CAMARA APIs are propagated to the operator's service through OSL's message queue (Active MQ), ensuring synchronization of service characteristics.
+
+> Assumption: The Operator already processes and exposes a 5G controlling running service
+
+This architectural approach is presented in the figure below:
+
+![CAMARAaaS-Architecture](./images/CAMARAaaS-Architecture.png)
+
+### **Components in the Architecture**
+
+---
+
+**Service Specification Catalogue**:
+
+- Stores the Service Specifications.
+- Contains the `CAMARA API Controller` Service Specification, which defines/exposes the profile enforcer functionality.
+
+**Service Inventory**:
+
+- Tracks service instances (e.g., RFS - Resource-Facing Services) and their configurations.
+- Includes services such as:
+    - CAMARA API Exposure Profile Enforcer
+    - 5G Network Slice
+    - Network profiles and UE (User Equipment) services
+
+**Resource Inventory**:
+
+- Holds information about resources provisioned in the system, related with the respective RFSs.
+- Contains resources like:
+    - CAMARA API Exposure
+    - Profile Enforcer
+    - 5G Core
+    - Configmaps (used for managing Kubernetes configurations)
+
+**Kubernetes Cluster**:
+
+- Hosts and manages the 5G Core components
+- Hosts all OSL operators (OSL can manage them these through CRIDGE - not depicted)
+- Facilitates configuration updates via ConfigMap and resource values
+
+**CAMARA API Controller**:
+
+- Processes API exposure requests and orchestrates resources for API exposure
+- Generates the CAMARA API Exposure resource on demand
+
+---
+
+### **Processes in the Workflow**
+
+
+There are three workflows depicted for a fully orchestrated end-to-end solution. The first one defines the prerequisites to deliver CAMARAaaS.
+
+The following two workflows explain how the CAMARAaaS is being delivered:
+
+**CAMARAaaS - Service Order Creation**:
+   
+- A Service Order is initiated to expose a CAMARA API Exposure service with parameter(`ExposeServiceUUID=Profile Enforcer`) using the TMF Service order API
+- This triggers the service provisioning process in the Service Inventory
+- A custom resource is created and requests via the CAMARA API controller to create the CAMARA API Exposure for the Service Profile Enforcer
+- The `CAMARA API Exposure` resource is created and populated with configuration values
+- The API Exposure resource is finalized in the cluster and made available for consumption via the ordered CAMARA API Exposure service.
+
+
+**CAMARA API Usage - Service Operation**:
+   
+- The API request includes QoD (Quality on Demand) parameters and is accessible via a specified NodePort and/or endpoint URL (e.g. `portal.osl/{serviceAUUID}/camaraapiFQDN`).
+- A client performs a CAMARA QoD Request.
+- An event is created and circulated within OSL message bus to notify about the request.
+- The event results into a TMF request that is used to patch and customize the Network Operator's Profile enforcer service in the Service Inventory.
+- The configuration is passed through OSL Orchestrator and CRIDGE down to the `5G Core Controller`.
+- The 5G Core Controller modifies the respective network configurations such as:
+    - Slices (5G Network Slice profiles)
+    - User equipment (UE) profiles
+- These changes are propagated to the Kubernetes-managed 5G Core components.
+- Resources in the Resource Inventory are updated to reflect the enforced requirements.
+- Updates are made to the `Configmap` Resource to align with the latest configurations.
+- These changes ensure that the 5G Core components operate with updated slice, profile, and UE configurations.
+- A similar event as in previous steps is generated that enables the CAMARA API to get notified by the enforced changes and update the client. 
+---
+
+This architecture emphasizes automation, modularity, and interoperability between CAMARA APIs and 5G Core Infrastructure, leveraging Kubernetes for seamless management and deployment.
+
+The first image below, displays a normal scenario of using OSL to deploy and change a running service deployed in a Kubernetes cluster, using Kubernetes CRDs. First the service is requested through a Service Order. For example, the requested service can be a Service Specification bundle consisting of:
+
+- a 5G Core Service Specification that will deploy a 5G Core through HELM chart(s).
+- a 5G Controller Service Specification (deployed via HELM) that can change configuration of slices for UEs. This 5G Controller might register further Kubernetes operators for reconfiguring the core, slices, etc. It is developed by the Network Operator and is able to reconfigure several components via e.g. NEF, scripting, API commands or other means.
+
+OSL deploys the services via a Service Order request. Then while the service is in operation (ACTIVE), the user that ordered it can submit reconfigurations (see loop in figure) by changing characteristics of the service. These characteristics are then propagated from OSL orchestrator, through CRIDGE, down to the 5G Controller Kubernetes resource to handle it.
+
+![CAMARAaaS-Workflow-OSLToday](./images/CAMARAaaS-Workflow-OSLToday.png)
+
+Since the 5G Controller Service is running since the previous step, the user requests to expose it via a certain CAMARA API. The user orders the respective CAMARA Controller to expose this service via CAMARA API. User just needs to pass the UUID identifier of the 5G Controller Service (facilitator of CAMARA Controller), as seen in TMF Service Inventory, during the Service Order request.
+
+![CAMARAaaS-Workflow-ServiceOrdering](./images/CAMARAaaS-Workflow-ServiceOrdering.png)
+
+Since the new CAMARA API service is active, clients can use this new API to reconfigure the service. This request is passed through the message bus to the TMF API and then down to the 5G Controller Service.
+
+As already mentioned, the steps that require to “Update Service Characteristics” are achieved by sending a message to OSL’s message bus.
+
+
+![CAMARAaaS-Workflow-ServiceOperation](./images/CAMARAaaS-Workflow-ServiceOperation.png)
+
+
+## Important Considerations
+
+The CAMARAaaS add-on depends on 2 Services:
+
+- The OSL CAMARA API Service
+    - Is a generic CAMARA API wrapper Service implemented by the OSL team
+    - This implementation is publicly offered as an OpenSlice add-on (Helm Chart)
+- A custom 5G-related Service (that shall be controlled/referenced by the CAMARA API Service)
+    - An OSL user must implement and provide its own 5G-related Controlling Service (following OSL design patterns)
+    - The implementation is custom
\ No newline at end of file

doc/addons/intro.md

+# OpenSlice Addons
+
+**Intended Audience: OpenSlice Service Designers**
+
+OpenSlice [Addons repository](https://labs.etsi.org/rep/osl/code/addons) introduces an archive of reusable and replicable projects that leverage OpenSlice architecture to enable telco cloud scenarios and expose capabilities of a modern Operator Platform.
+
+Stay tuned as addons are continuously updated!
\ No newline at end of file

doc/architecture/cridge/cridge_introduction.md → doc/architecture/cridge.md

@@ -41,7 +41,7 @@ Pros, in a nutshell:
  
 The following image illustrates the approach.
 
-![img01.png](img01.png)
+![img01.png](./images/cridge/img01.png)
 
 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. The OSL Orchestrator (OSOM) will manage the lifecycle of the Service Order.
@@ -52,7 +52,7 @@ The following image illustrates the approach.
 
 
 
-![img02.png](img02.png)
+![img02.png](./images/cridge/img02.png)
 
 
 
@@ -100,7 +100,7 @@ In a nutchell:
 A CRIDGE service is usually responsible for managing one cluster. In the following diagram we show how it can be used for managing multiple clusters:
 
 
-![img03.png](img03.png)
+![img03.png](./images/cridge/img03.png)
     	
 We assume that there is an OSL Management cluster that OSL is installed. CRIDGE is also installed there if we would like to manage resources in the same management cluster. 
 
@@ -119,7 +119,7 @@ We assume that there is an OSL Management cluster that OSL is installed. CRIDGE
 The implemented synchronization process is explained by the following diagram:
 
 
-![img04.png](img04.png)
+![img04.png](./images/cridge/img04.png)
 
  WatcherService is executed when the CRIDGE service application starts (see onApplicationEvent). Specifically:
  	
@@ -147,7 +147,7 @@ The implemented synchronization process is explained by the following diagram:
 
 ## Exposure of CRDs as Service Specifications 
 
-See [Exposing Kubernetes Resources](../../service_design/kubernetes/exposing_kubernetes_resources.md) section for ways to design services around CRDs.
+See [Exposing Kubernetes Resources](../service_design/kubernetes/exposing_kubernetes_resources.md) section for ways to design services around CRDs.
 
 
 ## Service Orchestration and CRDs/CRs
@@ -210,7 +210,7 @@ OSOM sends to CRIDGE a message with the following information:
 The implemented process to deploy a CR is explained by the following diagram:
 
 
-![img05.png](img05.png)
+![img05.png](./images/cridge/img05.png)
 
 - A message arrives to deploy a CR
 	- The call examines if this CRIDGE service can handle the request (based on context and masterURL)
@@ -223,9 +223,10 @@ The implemented process to deploy a CR is explained by the following diagram:
 
 ## Probe further
 
-- See examples of exposing Kubernetes Operators as a Service via OpenSlice:
-    - [Offering "Calculator as a Service"](../../service_design/examples/calculator_crd_aas/calculator_crd_aas.md)
-    - [Offering "Helm installation as a Service" (Jenkins example)](../../service_design/examples/jenkins_helm_install_aas/jenkins_helm_install_aas.md)
+See examples of exposing Kubernetes Operators as a Service via OpenSlice:
+
+- [Offering "Calculator as a Service"](../service_design/examples/calculator_crd_aas/calculator_crd_aas.md)
+- [Offering "Helm installation as a Service" (Jenkins example)](../service_design/examples/jenkins_helm_install_aas/jenkins_helm_install_aas.md)
  	
  	
  	

doc/architecture/messagebus.md

 # Message Bus and exchanged Messages
 
-Openslice has a Message bus which allows Openslice services to exchange messages via queues and topics.
+OpenSlice has a Message bus which allows OpenSlice services to exchange messages via queues and topics.
 
-It is based on ActiveMQ.
+It is based on ActiveMQ Artemis.
 
 3rd party services can be attached to bus and subscribe to message topics or request resources via queues.
 

doc/architecture/metrico.md

+
+# METRICO: A Service that integrates external monitoring data in OpenSlice
+
+<!-- **Intended Audience: OpenSlice Developers** -->
+
+## Introduction
+ 
+Services and Resources created through OpenSlice (OSL) potentially provide a vast amount of data and metrics during their runtime. These data could be leveraged to perform actions upon the said services. Before the introduction of the METRICO component, OSL would need to rely exclusively on external tools' implementation to report metrics to it.
+
+Not anymore! METRICO is a component designed to create an inherent mechanism that initiates customizable metrics-retrieval jobs and associate the data with services under scope. To address the challenge of data retrieval across multiple and heterogeneous environments, OSL is not coupling tightly with a monitoring solution, but is able to integrate with any monitoring stack that provides a programmable API, e.g. Prometheus. Prometheus is considered a widely-utilized monitoring solution and many alternative monitoring tools converge towards its data model via implementation of Prometheus Exporters. On the other hand, OSL remains technology agnostic by capturing the monitoring requirements (e.g., data source, queries, interval, etc) through the TMF628 Performance Management model and API.
+
+In a nutshell, METRICO allows OSL users to:
+
+- integrate already owned monitoring systems with OSL (also supporting several parallel integrations)
+- retrieve important metrics inherently through OpenSlice Service Inventory
+- natively empower the service lifecycle with external data through LCM rules
+- perform closed-loop control management
+ 
+## Approach
+
+OSL comprises of offered Service Specifications which, when ordered, create the respective Service instances, accessible through the Service Inventory (based on TMF638). The rationale behind the introduced component is that it exposes a defined METRICO Resource Specification which is used to design monitoring-related Service Specifications. The latter comprises of meaningful characteristics (e.g. monitoring data source, query, interval, affected service, etc) that are filled in by the requester.
+
+When the user orders a monitoring-related Service Specification (with populated characteristics of its preference) a TMF628 Measurement Collection Job entity is created which is responsible for gathering the requested metrics. Respecting the desired interval, this job returns the monitoring results to the appointed service in the Service Inventory, patching a designated characteristic.
+
+The following image illustrates the approach:
+
+![METRICO Architecture](./images/metrico/metrico_arch_introduction.png)
+
+Furthemore, all the interactions that occur from the time that an OSL User orders a monitoring-related Service Specification until the requested metrics are retrieved are depicted in the following sequence diagram.
+
+![METRICO Service Sequence Diagram](./images/metrico/metrico_service_sequence_diagram.png)
+
+## Probe further
+
+See guides and examples on creating Monitoring Jobs as a Service via OpenSlice:
+
+- [Design Monitoring Services](../service_design/monitoring/design_monitoring_services.md)
+- [Example: Integrate Prometheus monitoring solution as-a-Service](../service_design/examples/monitoring_aas/monitoring_aas.md)
+

doc/architecture/nfvapi.md

@@ -2,18 +2,18 @@
 
 ## OAuth token
 
-See [oauth](./oauth.md)
+See [oauth](./oauth.md).
 
 ## Request a protected API resource
 
 Example: Get all vxfs (check the `Authorization:Bearer` to be correct)
 
 ```
-curl -H "Authorization:Bearer eybGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX25hbWUiOiJhZG1pbiIsInNjb3BlIjpbIm9wZW5hcGkiLCJhZG1pbiIsInJlYWQiLCJ3cml0ZSJdLCJvcmdhbml6YXRpb24iOiJteW9yZ2FuaXp0aW9uIiwiZXhwIjoxNTcxOTI0MjU2LCJhdXRob3JpdGllcyI6WyJST0xFX01FTlRPUiIsIlJPTEVfQURNSU4iXSwianRpIjoiNzNkZmIxODEtNTMwOS00MmExLThkOWUtOGM3YmQ0YTE1YmU0IiwiY2xpZW50X2lkIjoib3NhcGlXZWJDbGllbnRJZE91dCJ9.Pj_hxnyMGhFhN8avU_DiAw1-LlcaIz5Hp9HNqalw-X4" http://localhost:13000/osapi/admin/vxfs
+curl -H "Authorization:Bearer eybGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX25hbWUiOiJhZG1pbiIsInNjb3BlIjpbIm9wZW5hcGkiLCJhZG1pbiIsInJlYWQiLCJ3cml0ZSJdLCJvcmdhbml6YXRpb24iOiJteW9yZ2FuaXp0aW9uIiwiZXhwIjoxNTcxOTI0MjU2LCJhdXRob3JpdGllcyI6WyJST0xFX01FTlRPUiIsIlJPTEVfQURNSU4iXSwianRpIjoiNzNkZmIxODEtNTMwOS00MmExLThkOWUtOGM3YmQ0YTE1YmU0IiwiY2xpZW50X2lkIjoib3NhcGlXZWJDbGllbnRJZE91dCJ9.Pj_hxnyMGhFhN8avU_DiAw1-LlcaIz5Hp9HNqalw-X4" http://portal.openslice.eu/osapi/admin/vxfs
 ```
 Example response:
 
-```
+```json
 [
   {
     "id": 1,

doc/architecture/oauth.md

@@ -10,26 +10,34 @@ All APIs (except grant token request) must include Bearer token in request Autho
 ##OAuth token
 
 Get first an oauth token, using your username and password. 
-```
+
+```bash
 curl -X POST http://portal.openslice.eu/auth/realms/openslice/protocol/openid-connect/token -H 'Content-Type: application/x-www-form-urlencoded' -d 'username=demouser' -d 'password=demouser' -d 'grant_type=password' -d 'client_id=osapiWebClientId' 
 ```
-response:
+Response:
 
-```
-                                                       {"access_token":"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJHZFRjQnpxczg2VW10NTRVZV8ybTJyWHJkV3dzaWdSZE9EUldMYm1memNvIn0.eyJleHAiOjE1ODgyNDA1NzAsImlhdCI6MTU4ODI0MDI3MCwianRpIjoiOGI2ZTU0NWUtNDIyYy00NzFiLWEwN2UtYTUzYzY1NDQ0MzZmIiwiaXNzIjoiaHR0cDovL3BvcnRhbC5vcGVuc2xpY2UuaW8vYXV0aC9yZWFsbXMvb3BlbnNsaWNlIiwiYXVkIjoiYWNjb3VudCIsInN1YiI6ImExYTI3NjVhLWVjODMtNDQ1Ni1iN2IyLTIwNzMxOTg2ZTAzNSIsInR5cCI6IkJlYXJlciIsImF6cCI6Im9zYXBpV2ViQ2xpZW50SWQiLCJzZXNzaW9uX3N0YXRlIjoiMzM1MGY0OTMtNjYyNy00MzczLTg1NDQtZGVmZDI3YWQzYzc0IiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vbG9jYWxob3N0OjEzMDgyIiwiaHR0cDovL2xvY2FsaG9zdCIsImh0dHA6Ly9vcGVuc2xpY2UuaW8iLCJodHRwOi8vbG9jYWxob3N0OjEzMDAwIiwiaHR0cDovL2xvY2FsaG9zdDo0MjAwIiwiaHR0cDovL3BvcnRhbC5vcGVuc2xpY2UuaW8iXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIk5GVl9ERVZFTE9QRVIiLCJvZmZsaW5lX2FjY2VzcyIsInVtYV9hdXRob3JpemF0aW9uIiwiRVhQRVJJTUVOVEVSIiwiVVNFUiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sInNjb3BlIjoicHJvZmlsZSBlbWFpbCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJkZW1vdXNlciJ9.TnzzpRLMD94UTKpT5_wkr1h4_3KUQmr4TGvFLpJ7cZx-Klrv8tB_eRkWnPqqzCAM9G21a1qXboL8MLMW8ECzG7HYKpobKOGr7LSczMOTdA2ZDyBCRUSOdW77pchu54tJ0ITEkFaDwSKMKKt04V_Sy4U-eIndj0XzzRlkDolWDnK4Z2lRaXAI6fMwOKx1Toa6RfOcemxtzl3pdtjPx92zo6MaKlbIqHK82lxdK0k8aQQaT6TmIrXbZKV2dU_1d3O0q0dVUEZJ_1kzwqOFkmxr9w0EnndC6ccYJlDAr_-GgUhhhNOn5v6tjYLUQdj5e4KEAsxIPzaCreK4un7mEAPmDw","expires_in":300,"refresh_expires_in":1800,"refresh_token":"eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICIwZjUxMDk5Yy0wNTIzLTRjNGQtODM0Zi1iNDc0YzBjOTA1MzkifQ.eyJleHAiOjE1ODgyNDIwNzAsImlhdCI6MTU4ODI0MDI3MCwianRpIjoiZmViOTg5NWEtOTY5ZS00MzIzLWJjY2QtZTY2YzQ0NGE1MzJlIiwiaXNzIjoiaHR0cDovL3BvcnRhbC5vcGVuc2xpY2UuaW8vYXV0aC9yZWFsbXMvb3BlbnNsaWNlIiwiYXVkIjoiaHR0cDovL3BvcnRhbC5vcGVuc2xpY2UuaW8vYXV0aC9yZWFsbXMvb3BlbnNsaWNlIiwic3ViIjoiYTFhMjc2NWEtZWM4My00NDU2LWI3YjItMjA3MzE5ODZlMDM1IiwidHlwIjoiUmVmcmVzaCIsImF6cCI6Im9zYXBpV2ViQ2xpZW50SWQiLCJzZXNzaW9uX3N0YXRlIjoiMzM1MGY0OTMtNjYyNy00MzczLTg1NDQtZGVmZDI3YWQzYzc0Iiwic2NvcGUiOiJwcm9maWxlIGVtYWlsIn0.cDTx9BE1Df8EfGYm3VLr_MNFeymxZtJhMtlK7PVbIuk","token_type":"bearer","not-before-policy":1586797346,"session_state":"3350f493-6627-4373-8544-defd27ad3c74","scope":"profile email"}
+```json
+{
+    "access_token":"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJHZFRjQnpxczg2VW10NTRVZV8ybTJyWHJkV3dzaWdSZE9EUldMYm1memNvIn0.eyJleHAiOjE1ODgyNDA1NzAsImlhdCI6MTU4ODI0MDI3MCwianRpIjoiOGI2ZTU0NWUtNDIyYy00NzFiLWEwN2UtYTUzYzY1NDQ0MzZmIiwiaXNzIjoiaHR0cDovL3BvcnRhbC5vcGVuc2xpY2UuaW8vYXV0aC9yZWFsbXMvb3BlbnNsaWNlIiwiYXVkIjoiYWNjb3VudCIsInN1YiI6ImExYTI3NjVhLWVjODMtNDQ1Ni1iN2IyLTIwNzMxOTg2ZTAzNSIsInR5cCI6IkJlYXJlciIsImF6cCI6Im9zYXBpV2ViQ2xpZW50SWQiLCJzZXNzaW9uX3N0YXRlIjoiMzM1MGY0OTMtNjYyNy00MzczLTg1NDQtZGVmZDI3YWQzYzc0IiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vbG9jYWxob3N0OjEzMDgyIiwiaHR0cDovL2xvY2FsaG9zdCIsImh0dHA6Ly9vcGVuc2xpY2UuaW8iLCJodHRwOi8vbG9jYWxob3N0OjEzMDAwIiwiaHR0cDovL2xvY2FsaG9zdDo0MjAwIiwiaHR0cDovL3BvcnRhbC5vcGVuc2xpY2UuaW8iXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIk5GVl9ERVZFTE9QRVIiLCJvZmZsaW5lX2FjY2VzcyIsInVtYV9hdXRob3JpemF0aW9uIiwiRVhQRVJJTUVOVEVSIiwiVVNFUiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sInNjb3BlIjoicHJvZmlsZSBlbWFpbCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJkZW1vdXNlciJ9.TnzzpRLMD94UTKpT5_wkr1h4_3KUQmr4TGvFLpJ7cZx-Klrv8tB_eRkWnPqqzCAM9G21a1qXboL8MLMW8ECzG7HYKpobKOGr7LSczMOTdA2ZDyBCRUSOdW77pchu54tJ0ITEkFaDwSKMKKt04V_Sy4U-eIndj0XzzRlkDolWDnK4Z2lRaXAI6fMwOKx1Toa6RfOcemxtzl3pdtjPx92zo6MaKlbIqHK82lxdK0k8aQQaT6TmIrXbZKV2dU_1d3O0q0dVUEZJ_1kzwqOFkmxr9w0EnndC6ccYJlDAr_-GgUhhhNOn5v6tjYLUQdj5e4KEAsxIPzaCreK4un7mEAPmDw",
+    "expires_in":300,
+    "refresh_expires_in":1800,
+    "refresh_token":"eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICIwZjUxMDk5Yy0wNTIzLTRjNGQtODM0Zi1iNDc0YzBjOTA1MzkifQ.eyJleHAiOjE1ODgyNDIwNzAsImlhdCI6MTU4ODI0MDI3MCwianRpIjoiZmViOTg5NWEtOTY5ZS00MzIzLWJjY2QtZTY2YzQ0NGE1MzJlIiwiaXNzIjoiaHR0cDovL3BvcnRhbC5vcGVuc2xpY2UuaW8vYXV0aC9yZWFsbXMvb3BlbnNsaWNlIiwiYXVkIjoiaHR0cDovL3BvcnRhbC5vcGVuc2xpY2UuaW8vYXV0aC9yZWFsbXMvb3BlbnNsaWNlIiwic3ViIjoiYTFhMjc2NWEtZWM4My00NDU2LWI3YjItMjA3MzE5ODZlMDM1IiwidHlwIjoiUmVmcmVzaCIsImF6cCI6Im9zYXBpV2ViQ2xpZW50SWQiLCJzZXNzaW9uX3N0YXRlIjoiMzM1MGY0OTMtNjYyNy00MzczLTg1NDQtZGVmZDI3YWQzYzc0Iiwic2NvcGUiOiJwcm9maWxlIGVtYWlsIn0.cDTx9BE1Df8EfGYm3VLr_MNFeymxZtJhMtlK7PVbIuk",
+    "token_type":"bearer",
+    "not-before-policy":1586797346,
+    "session_state":"3350f493-6627-4373-8544-defd27ad3c74",
+    "scope":"profile email"
+}
 
 ```
 
 The `access_token` will be used next as a Bearer.
 
+```bash
+curl http://portal.openslice.eu/tmf-api/serviceCatalogManagement/v4/serviceCatalog -H 'Authorization: Bearer {{access_token}}
 ```
-curl http://portal.openslice.eu/tmf-api/serviceCatalogManagement/v4/serviceCatalog -H 'Authorization: Bearer yJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJHZFRjQnpxczg2VW10NTRVZV8ybTJyWHJkV3dzaWdSZE9EUldMYm1memNvIn0.eyJleHAiOjE1ODgyNDA1MjQsImlhdCI6MTU4ODI0MDIyNCwianRpIjoiYjg0NGYxZDAtMzk3Mi00YTMyLThiMWEtZDAxMDY3OGZjMTQ4IiwiaXNzIjoiaHR0cDovL3BvcnRhbC5vcGVuc2xpY2UuaW8vYXV0aC9yZWFsbXMvb3BlbnNsaWNlIiwic3ViIjoiYTFhMjc2NWEtZWM4My00NDU2LWI3YjItMjA3MzE5ODZlMDM1IiwidHlwIjoiQmVhcmVyIiwiYXpwIjoiYWRtaW4tY2xpIiwic2Vzc2lvbl9zdGF0ZSI6ImFmMmMzZmY1LTE4YWQtNDFkNC1hYTAyLTFlMGJkNzNmOTM5MSIsImFjciI6IjEiLCJzY29wZSI6InByb2ZpbGUgZW1haWwiLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwicHJlZmVycmVkX3VzZXJuYW1lIjoiZGVtb3VzZXIifQ.SMtgV1E44_K_MQumGXZtWsLGVhYNaoM8Pk-DiFIZtUP4Zu-ervOsxHVQMX1frgVERR4jJidBcSshy9TnJ3UjF4l33WujHltbs-1UPy-gaIufVuEpl8RmbjOti3Up70vLfLXbzb6kN6WaahgobWXlbJsSXXwaBPQP6vSX5KigCa8TmzXcuqom14lOrlU-RB2zQTlJ30p7d9ag-a7o3I5m9GZWLJCZW2UYMl1JkskTHKgilA8HFQY4C9DYwWu8YDMyzqQSNumrTlURalBFidFbZvb1kp4dAyct8TysSWSbxxiwaL2RX1PWUqk-5Fpc1Q6BnBC8muMheiukFuoSkuADAg'^C
-ubuntu@portal:~$ curl http://portal.openslice.eu/tmf-api/serviceCatalogManagement/v4/serviceCatalog -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJHZFRjQnpxczg2VW10NTRVZV8ybTJyWHJkV3dzaWdSZE9EUldMYm1memNvIn0.eyJleHAiOjE1ODgyNDA1NzAsImlhdCI6MTU4ODI0MDI3MCwianRpIjoiOGI2ZTU0NWUtNDIyYy00NzFiLWEwN2UtYTUzYzY1NDQ0MzZmIiwiaXNzIjoiaHR0cDovL3BvcnRhbC5vcGVuc2xpY2UuaW8vYXV0aC9yZWFsbXMvb3BlbnNsaWNlIiwiYXVkIjoiYWNjb3VudCIsInN1YiI6ImExYTI3NjVhLWVjODMtNDQ1Ni1iN2IyLTIwNzMxOTg2ZTAzNSIsInR5cCI6IkJlYXJlciIsImF6cCI6Im9zYXBpV2ViQ2xpZW50SWQiLCJzZXNzaW9uX3N0YXRlIjoiMzM1MGY0OTMtNjYyNy00MzczLTg1NDQtZGVmZDI3YWQzYzc0IiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6WyJodHRwOi8vbG9jYWxob3N0OjEzMDgyIiwiaHR0cDovL2xvY2FsaG9zdCIsImh0dHA6Ly9vcGVuc2xpY2UuaW8iLCJodHRwOi8vbG9jYWxob3N0OjEzMDAwIiwiaHR0cDovL2xvY2FsaG9zdDo0MjAwIiwiaHR0cDovL3BvcnRhbC5vcGVuc2xpY2UuaW8iXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIk5GVl9ERVZFTE9QRVIiLCJvZmZsaW5lX2FjY2VzcyIsInVtYV9hdXRob3JpemF0aW9uIiwiRVhQRVJJTUVOVEVSIiwiVVNFUiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sInNjb3BlIjoicHJvZmlsZSBlbWFpbCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJkZW1vdXNlciJ9.TnzzpRLMD94UTKpT5_wkr1h4_3KUQmr4TGvFLpJ7cZx-Klrv8tB_eRkWnPqqzCAM9G21a1qXboL8MLMW8ECzG7HYKpobKOGr7LSczMOTdA2ZDyBCRUSOdW77pchu54tJ0ITEkFaDwSKMKKt04V_Sy4U-eIndj0XzzRlkDolWDnK4Z2lRaXAI6fMwOKx1Toa6RfOcemxtzl3pdtjPx92zo6MaKlbIqHK82lxdK0k8aQQaT6TmIrXbZKV2dU_1d3O0q0dVUEZJ_1kzwqOFkmxr9w0EnndC6ccYJlDAr_-GgUhhhNOn5v6tjYLUQdj5e4KEAsxIPzaCreK4un7mEAPmDw'
 
 Response:
 
-
+```json
 [{"uuid":"9e186cd5-b2b2-4a06-b1d6-895720193bc9","lastUpdate":"2020-03-11T23:19:05Z","@baseType":"BaseEntity","@schemaLocation":null,"@type":"ServiceCatalog","href":null,"name":"Example Facility Services","description":"Example Facility Services","lifecycleStatus":"Active","version":"1.0","validFor":{"endDateTime":"2039-11-20T23:07:21Z","startDateTime":"2019-11-20T23:07:21Z"},"relatedParty":null,"id":"9e186cd5-b2b2-4a06-b1d6-895720193bc9","category":[{"@baseType":"org.etsi.osl.tmf.scm633.model.ServiceCategoryRef","@schemaLocation":null,"@type":"org.etsi.osl.tmf.scm633.model.ServiceCategoryRef","href":null,"name":"Generic Services","@referredType":null,"id":"98b9adf1-a1d6-4165-855f-153ddc2131b1"},{"@baseType":"org.etsi.osl.tmf.scm633.model.ServiceCategoryRef","@schemaLocation":null,"@type":"org.etsi.osl.tmf.scm633.model.ServiceCategoryRef","href":null,"name":"External","@referredType":null,"id":"08ffdb3c-6237-45d0-9f3a-d43b5fc5f0b6"},{"@baseType":"org.etsi.osl.tmf.scm633.model.ServiceCategoryRef","@schemaLocation":null,"@type":"org.etsi.osl.tmf.scm633.model.ServiceCategoryRef","href":null,"name":"eMBB","@referredType":null,"id":"ef2c90dd-b65e-4a9f-a9c3-427c9fb0219b"}]}]
-
-
-```
+```
\ No newline at end of file

doc/architecture/tmfapi.md

@@ -6,13 +6,13 @@ PLease check the complete specification [here](http://portal.openslice.eu/tmf-ap
 
 ### OAuth token
 
-See [oauth](./oauth.md)
+See [oauth](./oauth.md).
 
 ### Request a protected API resource
 
 Example: Get all Service Catalogs (check the `Authorization:Bearer` to be correct)
 
-```
+```bash
 curl -H "Authorization:Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX25hbWUiOiJhZG1pbiIsInNjb3BlIjpbIm9wZW5hcGkiLCJhZG1pbiIsInJlYWQiLCJ3cml0ZSJdLCJvcmdhbml6YXRpb24iOiJteW9yZ2FuaXp0aW9uIiwiZXhwIjoxNTc4NTA1MDcyLCJhdXRob3JpdGllcyI6WyJST0xFX01FTlRPUiIsIlJPTEVfQURNSU4iXSwianRpIjoiMTFlNGYxYTUtZDY0Ny00YzA1LWE0ZGMtYWFhYzUyMjk4YzMwIiwiY2xpZW50X2lkIjoib3NhcGlXZWJDbGllbnRJZE91dCJ9.gm7cKdusDrdMRkxEiFU5sENKGRC1xwVj2SgPRmE9xxx"  -H  "accept: application/json;charset=utf-8" -X GET "http://portal.openslice.eu/tmf-api/serviceCatalogManagement/v4/serviceCatalog"
 
 ```
@@ -21,7 +21,7 @@ curl -H "Authorization:Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX25hb
 response:
 
 
-```
+```json
 [
   {
     "uuid": "9e186cd5-b2b2-4a06-b1d6-895720193bc9",

doc/contributing/developing.md → doc/contribute/developing.md

@@ -3,7 +3,7 @@
 
 OpenSlice backend services are mainly implemented with Java 17 or above and Spring Boot.
 
-OpenSlice uses various subsystems and depending on the module would you like to work, other subsystems must be present *(you can disable them though in the code, e.g. at docker-compose.yaml file)*.
+OpenSlice uses various subsystems and depending on the module would you like to work, other subsystems must be present *(you can disable them though in the code, e.g. at docker-compose.yaml file)*. 
 
 ## General requirements
 

doc/contributing/documenting.md → doc/contribute/documenting.md

-
 # Documenting
 
 OpenSlice's documentation runs on [MkDocs](https://www.mkdocs.org/).
@@ -8,18 +7,16 @@ OpenSlice's documentation runs on [MkDocs](https://www.mkdocs.org/).
 Documenting OpenSlice is limited to active contributors. So, if you:
 
 1. are an active member or participant;
-
 2. wish to contribute to it;
-
 3. you're ready!
 
-## Documentation System and Structure
+## System and Structure
 
 [MkDocs](https://www.mkdocs.org/) is a fast and simple static site generator that's geared towards building project documentation. Documentation source files are written in `Markdown`, and configured with a single `YAML` configuration file. Start by reading the [introductory tutorial](https://www.mkdocs.org/getting-started/), then check the [User Guide](https://www.mkdocs.org/user-guide/) for more information.
 
 ## Getting Started
 
-To contribute to OpenSlice's documentation, you need to follow those easy steps:
+To contribute to OpenSlice's documentation, you need to follow these easy steps:
 
 1) Clone the [Documentation repository](https://labs.etsi.org/rep/osl/documentation) with:
 
@@ -27,14 +24,14 @@ To contribute to OpenSlice's documentation, you need to follow those easy steps:
 git clone https://labs.etsi.org/rep/osl/documentation.git
 ```
 
-2) Checkout the develop branch (incoming contributions are only accepted to the develop branch):
+2) Checkout the develop branch (incoming contributions are only accepted to the **develop** branch):
 
 ```bash
 cd ./documentation
 git checkout develop
 ```
 
-3) Setup a local mkdocs server, using a virtual environment
+3) Setup a local ``mkdocs`` server with a virtual environment:
 
 === "Linux + macOS"
 
@@ -42,13 +39,6 @@ git checkout develop
     python3 -m venv venv
     source venv/bin/activate
     ```
-    ``` bash
-    python -m pip install mkdocs
-    python -m pip install mkdocs-material
-    python -m pip install mkdocs-glightbox
-    python -m pip install mkdocs-markdownextradata-plugin
-    python -m pip install mike
-    ```
 
 === "Windows"
 
@@ -56,23 +46,35 @@ git checkout develop
     python -m venv venv
     venv\Scripts\activate
     ```
-    ``` bash
-    python -m pip install mkdocs
-    python -m pip install mkdocs-material
-    python -m pip install mkdocs-glightbox
-    python -m pip install mkdocs-markdownextradata-plugin
-    python -m pip install mike
-    ```
 
+``` bash
+python -m pip install -r requirements.txt
+```
 
-4) Wait for all downloads to finish and start the mkdocs server
+4) Wait for all downloads to finish and start the local ``mkdocs`` server:
 
 ```bash
 mkdocs serve
 ```
 
-5) Document (and commit)! 😊
+5) Document! 😊
+
+> You should always make sure that the local *MkDocs* server terminal is not producing any `INFO`/``WARNING`` messages regarding your contributions.
+
+### Add Documentation During Development
+
+To update the documentation properly during development, follow those additional steps:
+
+1. Create an issue on the documentation [GitLab](https://labs.etsi.org/rep/osl/documentation/-/issues) repository;
+2. Create a new branch with the **develop** branch as a source;
+3. Update the documentation and any relevant parts (ie: the ``index.md`` with new functionalities for the latest version);
+4. Check if errors are not being produced by ``mkdocs`` [locally](#getting-started);
+5. Commit and push changes to the new branch;
+6. Create a MR request towards **develop**;
+7. Send the request for review and approval to at least one **TSC Member**.
+
+> The documentation website supports branches, so your accepted changes will be reflected to the **develop** branch which then becomes the **release** branch after each corresponding cycle.
 
-Before committing, you should make sure that the local mkdcocs server's terminal is not producing any INFO/WARNING message regarding your contributions.
+##  Learn more
 
-> The documentation website supports branches, so your accepted changes will be reflected to the develop branch which becomes the Release branch after each corresponding cycle.
+If you wish to learn more about the documentation system, check [this link](https://labs.etsi.org/rep/osl/documentation/README.md).
\ No newline at end of file