diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index a4f7250af07235a5cbb9d7849c9a2733fc95dc12..546702b0076f6bec606588cd5855295a0880bb57 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -4,7 +4,7 @@ pages:
variables:
PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
PAGES_BRANCH: gl-pages
- HTTPS_REMOTE: https://gitlab-ci-token:${ACCESS_TOKEN}@${CI_SERVER_HOST}/rep/${CI_PROJECT_PATH}.git
+ HTTPS_REMOTE: https://gitlab-ci-token:${DOC_PROJECT_ACCESS_TOKEN}@${CI_SERVER_HOST}/rep/${CI_PROJECT_PATH}.git
before_script:
- pip install -q mkdocs-material mkdocs-glightbox mkdocs-markdownextradata-plugin mike
- apt-get update -qq && apt-get -qq install -y git > /dev/null
diff --git a/README.md b/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..004a1892942bf68d2b27e461d1b348103b2ae2c3
--- /dev/null
+++ b/README.md
@@ -0,0 +1,59 @@
+# Documentation
+
+This respository contains the documentation of OpenSlice.
+
+## Getting Started
+
+Please check the relevant document at [documenting.md](doc/contribute/documenting.md).
+
+## How does it work?
+
+There are 2 ways to upgrade documentation published on the [OSL Documentation] website:
+
+ * Push any change on **develop** branch will force update of the **develop** version on the [OSL Documentation] website;
+ * Create a tag, this will create a version with the tag name on the [OSL Documentation] website.
+
+### Branches
+
+This documentation repository has 2 protected branches:
+
+ * **main**: stable timeline on which tags are made;
+ * **develop**: edge timeline, also published on the [OSL Documentation] website.
+
+### Structure
+
+In the `mkdocs.yml` file you will find the navigation structure of the documentation, there you can sections with sub-sections.
+
+*For example:*
+
+```yaml
+nav:
+ - Overview:
+ - Introduction: index.md
+ - Deployment examples: deployment_examples.md
+ - History: history.md
+ - OpenSlice under ETSI: etsi_osl.md
+ - Getting Started:
+ - Deployment:
+ - Introduction: ./getting_started/deployment/introduction.md
+ - Docker Compose: ./getting_started/deployment/docker_compose.md
+ - Kubernetes: ./getting_started/deployment/kubernetes.md
+ - Portals: ./getting_started/portals.md
+[...]
+```
+
+Please take a moment to understand the current structure of the documentations and think to update after contributing if necessary.
+
+### Main Page
+
+The page shown first is at **doc/index.md**. That page should be updated with the latest changes of OpenSlice and should reference the version (useful shortcut is ``{{{ documentation_version }}}``).
+
+### Release a New Version of the Documentation
+
+When **OpenSlice** code repository is ready for a new release, we need to follow these steps (made by a **TSC Member**):
+
+1. Create a MR from **develop** towards **main**;
+2. When **develop** is merged to **main**... then **create a tag with the released version** scheme... and you're done!
+
+[OSL Web]: https://osl.etsi.org/ "OSL Web"
+[OSL Documentation]: https://osl.etsi.org/documentation/ "OSL Documentation"
\ No newline at end of file
diff --git a/doc/addons/camara/images/CAMARA-QoDProvisioning-API-Endpoints.png b/doc/addons/camara/images/CAMARA-QoDProvisioning-API-Endpoints.png
new file mode 100644
index 0000000000000000000000000000000000000000..b0fee4ea886564af09d804abc4343151d9dfa1c1
Binary files /dev/null and b/doc/addons/camara/images/CAMARA-QoDProvisioning-API-Endpoints.png differ
diff --git a/doc/addons/camara/images/CAMARAaaS-Architecture.png b/doc/addons/camara/images/CAMARAaaS-Architecture.png
new file mode 100644
index 0000000000000000000000000000000000000000..16a8d378264e92aaf0d214026dd7a5883833d838
Binary files /dev/null and b/doc/addons/camara/images/CAMARAaaS-Architecture.png differ
diff --git a/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Active-Services.png b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Active-Services.png
new file mode 100644
index 0000000000000000000000000000000000000000..0db82e2ade75e445b0d6bc15f4f3c1712ccfda21
Binary files /dev/null and b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Active-Services.png differ
diff --git a/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-CR.png b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-CR.png
new file mode 100644
index 0000000000000000000000000000000000000000..f13ab200fc2134da69c27ded1046dc7d6415ed28
Binary files /dev/null and b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-CR.png differ
diff --git a/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Characteristics-After-CAMARA-Invoking.png b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Characteristics-After-CAMARA-Invoking.png
new file mode 100644
index 0000000000000000000000000000000000000000..d5a0b0f1db42fadae5c950e3f55badba479b713d
Binary files /dev/null and b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Characteristics-After-CAMARA-Invoking.png differ
diff --git a/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Characteristics.png b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Characteristics.png
new file mode 100644
index 0000000000000000000000000000000000000000..68b03b17eb2749f8df9cfaf44e5f6f3840e98376
Binary files /dev/null and b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Characteristics.png differ
diff --git a/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Ordering.png b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Ordering.png
new file mode 100644
index 0000000000000000000000000000000000000000..1f85d2a8ce4a850ef7a896b22f3f33f5989511e8
Binary files /dev/null and b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Ordering.png differ
diff --git a/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Pre-Provision-Rule.png b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Pre-Provision-Rule.png
new file mode 100644
index 0000000000000000000000000000000000000000..09bd1f6d7b6b14da0e90736be41386e8fa30e5d9
Binary files /dev/null and b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Pre-Provision-Rule.png differ
diff --git a/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Supervision-Rule.png b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Supervision-Rule.png
new file mode 100644
index 0000000000000000000000000000000000000000..e08ec3ea0816e5b2ce8d8cc57854afb76ac407f6
Binary files /dev/null and b/doc/addons/camara/images/CAMARAaaS-QoD-Prov-API-Supervision-Rule.png differ
diff --git a/doc/addons/camara/images/CAMARAaaS-Workflow-OSLToday.png b/doc/addons/camara/images/CAMARAaaS-Workflow-OSLToday.png
new file mode 100644
index 0000000000000000000000000000000000000000..1f0e3c285aaec4a12d26e0acdc606be09be2a3a8
Binary files /dev/null and b/doc/addons/camara/images/CAMARAaaS-Workflow-OSLToday.png differ
diff --git a/doc/addons/camara/images/CAMARAaaS-Workflow-ServiceOperation.png b/doc/addons/camara/images/CAMARAaaS-Workflow-ServiceOperation.png
new file mode 100644
index 0000000000000000000000000000000000000000..9a451b2ecba49978c734dd05c753737889231423
Binary files /dev/null and b/doc/addons/camara/images/CAMARAaaS-Workflow-ServiceOperation.png differ
diff --git a/doc/addons/camara/images/CAMARAaaS-Workflow-ServiceOrdering.png b/doc/addons/camara/images/CAMARAaaS-Workflow-ServiceOrdering.png
new file mode 100644
index 0000000000000000000000000000000000000000..8b10df21a6eac26d73d4ab60d3c6af464b461a9f
Binary files /dev/null and b/doc/addons/camara/images/CAMARAaaS-Workflow-ServiceOrdering.png differ
diff --git a/doc/addons/camara/images/DummyOperatorService-Characteristics-After-CAMARA-Invoking.png b/doc/addons/camara/images/DummyOperatorService-Characteristics-After-CAMARA-Invoking.png
new file mode 100644
index 0000000000000000000000000000000000000000..4fa0a94c30341b6f031e8c16dee8e0cabd905061
Binary files /dev/null and b/doc/addons/camara/images/DummyOperatorService-Characteristics-After-CAMARA-Invoking.png differ
diff --git a/doc/addons/camara/images/DummyOperatorService-CustomResource.png b/doc/addons/camara/images/DummyOperatorService-CustomResource.png
new file mode 100644
index 0000000000000000000000000000000000000000..97b9452c42aba6ac7e5e726d99e176fdb7814786
Binary files /dev/null and b/doc/addons/camara/images/DummyOperatorService-CustomResource.png differ
diff --git a/doc/addons/camara/images/DummyOperatorService-Pre-Provision-Rule.png b/doc/addons/camara/images/DummyOperatorService-Pre-Provision-Rule.png
new file mode 100644
index 0000000000000000000000000000000000000000..8de481239e3954ee2f33d9a75d01e2b868ec0757
Binary files /dev/null and b/doc/addons/camara/images/DummyOperatorService-Pre-Provision-Rule.png differ
diff --git a/doc/addons/camara/images/DummyOperatorService-ResourceInventory.png b/doc/addons/camara/images/DummyOperatorService-ResourceInventory.png
new file mode 100644
index 0000000000000000000000000000000000000000..7864d9534f868b101e55ff6d10d0298f443f61a3
Binary files /dev/null and b/doc/addons/camara/images/DummyOperatorService-ResourceInventory.png differ
diff --git a/doc/addons/camara/images/DummyOperatorService-ServiceOrder.png b/doc/addons/camara/images/DummyOperatorService-ServiceOrder.png
new file mode 100644
index 0000000000000000000000000000000000000000..e0054c319c533a78a906fe2222944bfd525b17ed
Binary files /dev/null and b/doc/addons/camara/images/DummyOperatorService-ServiceOrder.png differ
diff --git a/doc/addons/camara/images/DummyOperatorService-Supervision-Rule.png b/doc/addons/camara/images/DummyOperatorService-Supervision-Rule.png
new file mode 100644
index 0000000000000000000000000000000000000000..853e3bd0a8590a31e9a142fb910f37fe7d7b672a
Binary files /dev/null and b/doc/addons/camara/images/DummyOperatorService-Supervision-Rule.png differ
diff --git a/doc/addons/camara/images/QoDProvisioningAPI-Docs.png b/doc/addons/camara/images/QoDProvisioningAPI-Docs.png
new file mode 100644
index 0000000000000000000000000000000000000000..228fa75ab819509f16da8f20a2a7c5412bc1141d
Binary files /dev/null and b/doc/addons/camara/images/QoDProvisioningAPI-Docs.png differ
diff --git a/doc/addons/camara/intro.md b/doc/addons/camara/intro.md
new file mode 100644
index 0000000000000000000000000000000000000000..c9532b9ee48b78b46ee26dbd6141eeabd47ba5fe
--- /dev/null
+++ b/doc/addons/camara/intro.md
@@ -0,0 +1,140 @@
+
+# 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:
+
+
+
+### **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.
+
+
+
+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.
+
+
+
+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.
+
+
+
+
+
+## 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
diff --git a/doc/addons/camara/qod.md b/doc/addons/camara/qod.md
new file mode 100644
index 0000000000000000000000000000000000000000..f21a4991d7d155eee8794bd90265f3917e698dd2
--- /dev/null
+++ b/doc/addons/camara/qod.md
@@ -0,0 +1,447 @@
+
+
+# Quality on Demand API Proof of Concept
+
+## Candidate CAMARA API - QoD Provisioning
+
+For this Proof of Concept (PoC), we decided to rely on the [CAMARA QoD Provisioning API](https://editor.swagger.io/?url=https://raw.githubusercontent.com/camaraproject/QualityOnDemand/r1.2/code/API_definitions/qod-provisioning.yaml).
+
+Such API has the following endpoints:
+
+
+
+Our solution needs to be deployed in a Kubernetes cluster. A 5G Core is needed for proper implementation as well as your own 5G Core Controller.
+
+The PoC is based on [OSL CAMARAaaS Add-on](./intro.md). It is recommended to read this before diving into the implementation of the PoC.
+
+To replicate this PoC you have to close the code found in the [CAMARA Addon project](https://labs.etsi.org/rep/osl/code/addons/org.etsi.osl.controllers.camara/-/tree/main/QoDProvisioning).
+
+## General concepts of the OSL CAMARAaaS as a TMF Service Specification
+
+First step is to design and expose the OSL CAMARA API service via the TMF models (Service Specification that can be ordered). The OSL CAMARA API service uses as backend connectivity the OSL message bus (OSL’s Active MQ broker). It exposes the CAMARA API, translates and forwards the requests to TMF Service Inventory model via the service bus. Therefore, considering the interactions that shall take place between the exposed CAMARA API, the Operator’s running 5G Controller Service and the architecture introduced before, the OSL CAMARA API exposure service must interface with OSL’s Active MQ broker. Moreover, for this first prototype the OSL's CAMARAaaS will be delivered via a Service Order. To enable this, we need to design it in OpenSlice as a Service Specification, so in general some TMF service characteristics are required to pass this information to the OSL CAMARA API exposure service which will be orchestrated, deployed and configured through OSL:
+
+- **messageBroker.address** - OSL's ActiveMQ Address (e.g. 10.10.10.10)
+- **messageBroker.port** - OSL's ActiveMQ Port
+- **messageBroker.username** - OSL’s ActiveMQ Username
+- **messageBroker.password** - OSL’s ActiveMQ Password
+
+Additionally, we also need another Service Characteristic to store the UUID of the Operator’s running 5G Controller Service that will be triggered through the CAMARA API:
+
+- *serviceUnderControl.uuid*
+
+Considering that the CAMARA API will be orchestrated by OSL, the client does not know where the API will be deployed, nor the credentials used to access it. Therefore, 4 additional characteristics are required. These will be automatically updated by OSL after the CAMARA API Service is deployed:
+
+- **camaraAPI.url** - URL of the CAMARA API orchestrated by this service (view-only). This field will be automatically populated when the CAMARA API starts running
+- **camaraAPI.username** - Username of the CAMARA API orchestrated by this service (view-only). This field will be automatically populated when the CAMARA API starts running
+- **camaraAPI.password** - Password of the CAMARA API orchestrated by this service (view-only). This field will be automatically populated when the CAMARA API starts running
+- **camaraAPI.status** - This characteristic (view-only) will be populated with the CAMARA API status (RUNNING, NOT_RUNNING)
+
+Additionally, you may create a characteristic titled “*camaraAPI.results*â€, which you can use to have visibility of the QoD Provisionings processed by the API, at OSL level. Still, this characteristic is not required.
+
+Therefore, OSL’s CAMARAaaS (QoD API exposure service) will contain the following TMF Service Characteristics:
+
+- *messageBroker.address*
+- *messageBroker.port*
+- *messageBroker.username*
+- *messageBroker.password*
+- *serviceUnderControl.uuid*
+- *camaraAPI.url*
+- *camaraAPI.username*
+- *camaraAPI.password*
+- *camaraAPI.status*
+- *camaraAPI.results*
+
+### Broker Connection
+
+This API has a *ServiceEventManager* class that communicates with OSL's ActiveMQ broker through two topics:
+
+- `CATALOG.UPD.SERVICE`: Topic for catalog updates.
+- `EVENT.SERVICE.ATTRCHANGED`: Topic for service attribute changes.
+
+### CATALOG.UPD.SERVICE
+
+Whenever a new provisioning is created for an UE, the *ServiceEventManager*'s *update_service* method is called. This method sends a service update message through OpenSlice's *CATALOG.UPD.SERVICE* topic. When OSL receives the request, it updates the Operator's 5G Controller Service with the new characteristics, which are then caught and materialized by the correspondent Kubernetes Operator. After processing the request, the Operator adds the result to the CR-related service characteristic, i.e. *camaraResults*.
+
+### EVENT.SERVICE.ATTRCHANGED
+
+The *ServiceEventManager* subscribes to this topic to obtain and process the update messages regarding the specified Operator's 5G Controller Service, namely the UE QoD Profile Enforcer OSL service. Whenever this service's characteristics are updated in OSL, this class catches the update message. Then, the class extracts the *camaraResults* characteristic, which contains all QoS provisionings applied to the UE(s).
+
+These results are then processed by the *CamaraResultsProcessor* class, which updates each provisioning accordingly in the database.
+
+## General concepts of the QoD service (the 5G Core Provider/Operator Service) as OSL TMF Service Specification
+
+Having chosen the candidate API, the first step is to find a way to map the possible requests to TMF Service characteristics of the Operator’s service. Our approach in general is the following:
+
+- Design the QoD service that will accept the necessary QoD related characteristics
+- Implement the QoD service as a controller able to manage your 5G Core
+- Deploy it in a kubernetes cluster that OSL can manage (via CRIDGE)
+
+By looking at API’s specification, it is clear that at least 3 operations are required: (i) the creation of a QoD profile, (ii) its deletion, and (iii) listing all active QoD profiles. Therefore, we can proceed with evaluating the payload required for creating a QoD Provisioning. This payload involves various fields, which can be translated to the TMF Service Characteristics:
+
+- *qodProv.device.phoneNumber*
+- *qodProv.device.networkAccessIdentifier*
+- *qodProv.device.ipv4Address.privateAddress*
+- *qodProv.device.ipv4Address.publicAddress*
+- *qodProv.device.ipv4Address.publicPort*
+- *qodProv.device.ipv6Address*
+- *qodProv.qosProfile*
+- *qodProv.sink*
+- *qodProv.sinkCredential.credentialType*
+
+In order to support interaction with the previously defined OSL’s CAMARAaaS and alignment the CAMARA QoD Provisioning API models in general, the QoD service must be designed, at least, with these characteristics.
+
+Still, since there are various operations that can take place (CREATE and DELETE), a characteristic is also needed to map this. Therefore, the Operator's QoD service must also have a characteristics titled *qodProv.operation*. The DELETE operation is achieved based on a provisioning Id, and therefore the respective characteristics is needed: *qodProv.provisioningId.*
+
+Finally, characteristic is required to store the provisionings that were enforced by the Operator's QoD service. We can define this characteristic as *camaraResults*.
+
+Therefore, for an Operator’s service to be controlled by OSL’s CAMARAaaS specification, it needs to be designed with, at least, the following characteristics:
+
+- *qodProv.device.phoneNumber*
+- *qodProv.device.networkAccessIdentifier*
+- *qodProv.device.ipv4Address.privateAddress*
+- *qodProv.device.ipv4Address.publicAddress*
+- *qodProv.device.ipv4Address.publicPort*
+- *qodProv.device.ipv6Address*
+- *qodProv.qosProfile*
+- *qodProv.sink*
+- *qodProv.sinkCredential.credentialType*
+- *qodProv.operation*
+- *qodProv.provisioningId*
+- *camaraResults*
+
+Additional characteristics are fully supported. Those can be custom characteristics that are required by the Operator's QoD Service.
+
+In regard to the *camaraResults* characteristic, to allow interoperability, it must store a Stringified JSON Array with the enforced QoD Provisionings. **The schema of each provisioning should be the one defined in CAMARA’s QoD Provisioning API Specification.**
+
+
+## How To / Demonstration
+
+### 1. Dummy QoD Kubernetes Operator Service Design
+
+For this prototype, since we cannot deliver a QoD Service implementation for a specific commercial core, we created a Dummy QoD Kubernetes Operator Service which emulates the 5G Core configuration. In future releases of OSL we will offer solutions for some open source 5G cores, and/or some code templates to build your own 5G Core Operator.
+
+We will start by looking at the Dummy QoD Kubernetes Operator Service we have created to demonstrate this Add-on. The Service will be offered as a simple Custom Resource (CR) deployed in a Kubernetes cluster. You may find its Custom Resource Definition (CRD) under `/DummyOperatorService/crd.yaml` Look at the CRD fields. Please notice that these were defined according with what we introduced in the previous section.
+
+The first step is then to install this CRD in your kubernetes cluster. To this end, you may use the following command: `make create-dummy-operator-crd`
+
+After creating the CRD in your Kubernetes cluster, you may access OSL’s Resource Inventory and you will see the just created resource there.
+
+
+
+We need now to start offering this as-a-Service, ready to be ordered from the Service Catalogue. So, the first step is to create a Resource-Facing-Service (RFS) Specification to expose this resource. To do so, you may read the [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](../../service_design/examples/calculator_crd_aas/calculator_crd_aas.md) documentation page.
+
+Regarding the RFS Service, you must set the following characteristics:
+
+- _CR_CHECKVAL_AVAILABLE = RUNNING
+- _CR_CHECK_FIELD = spec.status
+
+By setting these characteristics, you will rely on the value of `spec.status` to set the service as `active`. Ideally, the 5G Core provider would have implemented a proper Kubernetes Operator for this Custom Resource to implement the requested QoD. However, as discussed already, for demonstration purposes, we will short-circuit the behavior and we will set `spec.status` to `RUNNING` immediately after deployment.
+
+
+Then, you can proceed to create a Customer-Facing-Service (CFS) Specification, which will incorporate the just created RFS Service. More information is available at: [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](../../service_design/examples/calculator_crd_aas/calculator_crd_aas.md). To create the CFS Service's characteristics, you may use the Service Specification available at `/DummyOperatorService/OSLArtifacts/DummyOperatorService-CFS-Specification.json` . You may manually create the CFS Service, or you may onboard this Service Specification by making a POST request to `{{url}}/tmf-api/serviceCatalogManagement/v4/serviceSpecification`.
+
+After creating the CFS Specification, you should mark this Service as a Bundle. Then, go to “Service Specification Relationships†and add the previous created RFS Specification.
+
+Regarding the LCM Rules for the CFS Service, you should configure the following ones:
+
+
+**[Pre-Provision Rule] - Short-circuits RFS/Sets RFS's spec.status to "Running"**
+
+
+
+<details>
+<summary>Pre-Provision Rule Java code</summary>
+
+```java
+{
+java.util.HashMap<String,String> charvals = new java.util.HashMap<>();
+charvals.put("_CR_SPEC",String.format("""
+apiVersion: org.etsi.osl/v1
+kind: DummyOperatorService
+metadata:
+ name: _to_be_replaced_by_osl
+ namespace: default
+spec:
+ status: "%s"
+"""
+, "RUNNING"));
+setServiceRefCharacteristicsValues("Dummy Operator Service - RFS", charvals);
+}
+```
+</details>
+
+**[Supervision Rule] - Detects changes to the Operator's CFS and reflects them and forwards them to RFS**
+
+
+
+
+<details>
+<summary>Supervision Rule Java code</summary>
+
+```java
+{
+java.util.HashMap<String,String> charvals = new java.util.HashMap<>();
+charvals.put("_CR_SPEC",String.format("""
+apiVersion: org.etsi.osl/v1
+kind: DummyOperatorService
+metadata:
+ name: _to_be_replaced_by_osl
+ namespace: default
+spec:
+ qodProv:
+ operation: "%s"
+ provisioningId: "%s"
+ device:
+ phoneNumber: "%s"
+ networkAccessIdentifier: "%s"
+ ipv4Address:
+ publicAddress: "%s"
+ privateAddress: "%s"
+ publicPort: %d
+ ipv6Address: "%s"
+ qosProfile: "%s"
+ sink: "%s"
+ sinkCredential:
+ credentialType: "%s"
+"""
+, getCharValAsString("qodProv.operation"), getCharValAsString("qodProv.provisioningId"), getCharValAsString("qodProv.device.phoneNumber"), getCharValAsString("qodProv.device.networkAccessIdentifier"), getCharValAsString("qodProv.device.ipv4Address.publicAddress"), getCharValAsString("qodProv.device.ipv4Address.privateAddress"), getCharValNumber("qodProv.device.ipv4Address.publicPort"), getCharValAsString("qodProv.device.ipv6Address"), getCharValAsString("qodProv.qosProfile"), getCharValAsString("qodProv.sink"), getCharValAsString("qodProv.sinkCredential.credentialType")));
+setServiceRefCharacteristicsValues("Dummy Operator Service - RFS", charvals);
+}
+setCharValFromStringType("camaraResults", getServiceRefPropValue("Dummy Operator Service - RFS", "serviceCharacteristicValue", "spec.camaraResults"));
+```
+</details>
+
+
+You can find the `_CR_SPEC` template used for the pre-provision rule at `/DummyOperatorService/OSLArtifacts/cr-template-pre-provision.yaml` . The `_CR_SPEC` template used for the supervision rule is available at `/DummyOperatorService/OSLArtifacts/cr-template-supervision.yaml`
+
+After that, you may expose this service via OSL’s Service Catalog, and order it. You do not need to configure any characteristics when ordering this Service. Confirm that the Service Order was completed, both RFS and CFS Services are active, and a Custom Resource of type *DummyOperatorService* was created in your Kubernetes Cluster. See images below:
+
+
+
+
+
+### 2. OSL CAMARAaaS QoD Provisioning API exposure Service Design
+
+Then, we can proceed to design the CAMARAaaS QoD Provisioning API exposure Service Specification in OSL catalogue. To this end, OSL’s team has implemented in Python the CAMARAaaS QoD Provisioning API, created a CRD to offer it, and developed a Kubernetes Operator to deal with its internal logic.
+
+
+#### 2.1 OSL CAMARAaaS QoD Provisioning API - Kubernetes Operator
+
+The previous docker image shall make available the CAMARA QoD Provisioning API. However, these API will be made available through Custom Resources of Type `CAMARAaaS-QoDProvisiongAPI`. Therefore, we also need a Kubernetes Operator to manage these resources. The Operator’s code can be found under `/QoDProvisioningAPI/Operator`. There, you have the source code of the Kubernetes Operator. The Operator's Helm Chart uses the default OSL registry docker images. If you are interesting in developing your own, please refer to the Makefile. To install the Operator, run the following command:
+
+```bash
+helm install camaraaas-qod-prov-operator ./QoDProvisioningAPI/Operator/chart --namespace <namespace_where_the_operator_shall_be_deployed> --create-namespace
+```
+
+After this, check if the operator is running through the `make get-operator-logs` command.
+
+If everything went ok, you should have a new CRD in your Kubernetes cluster. Run this command to verify if it was created: `kubectl describe crd camaraaas-qod-provisioning-apis.org.etsi.osl`.
+
+Before designing the service in OSL, let us first create a CR of type `CAMARAaaS-QoDProvisiongAPI` to validate that the operator is behaving according to what is expected. To this end, you may use the test custom resource available at `/QoDProvisioningAPI/Operator/test-cr.yaml` . Before creating the resource, you need to update the fields: *spec.messageBroker.address*, *spec.messageBroker.port, spec.messageBroker.username, spec.messageBroker.password*, with the values that relate with your OSL instance. The default values will be the following ones:
+
+- **spec.messageBroker.address:** {your OSL address}
+- **spec.messageBroker.port**: 61613
+- **spec.messageBroker.username**: artemis
+- **spec.messageBroker.password**: artemis
+
+For now, you do not need to update the field serviceUnderControl.uuid. You may leave it as is.
+
+After these updates, create the CR by running the command: `make create-operator-test-cr`.
+
+When the CR is created, its operator will deploy the CAMARA QoD API in a pod and expose it via a K8s Node Port. The URL where the API is available is published under the CR field `spec.camaraAPI.url` (e.g. [http://10.255.28.73:32630](http://10.255.28.73:32630/)). Check this field by running `make describe-operator-test-cr`. To confirm the API is running, access *<URL>/docs*. You should see the following:
+
+
+
+If you see this page, the CAMARA QoD Provisioning API Custom Resources and their operator is working. You may delete the Custom Resource you created. Run the following command: `make delete-operator-test-cr`.
+
+#### 2.2 OSL CAMARAaaS QoD Provisioning API - TMF Service Specification Design
+
+Now we can proceed to create an OSL TMF Service Specification that maps the CAMARAaaS QoD Provisioning API CR, ready to be ordered in your OSL Service Specification Catalogue.
+
+The first step is to create an RFS Service to expose this resource. To do so, you may read the [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](../../service_design/examples/calculator_crd_aas/calculator_crd_aas.md) documentation page.
+
+Regarding the RFS Service, you must set the following characteristics:
+
+- _CR_CHECKVAL_AVAILABLE = RUNNING
+- _CR_CHECK_FIELD = spec.camaraAPI.status
+
+By setting this characteristics, you will rely on the value of `spec.camaraAPI.status` to set the service as `active`. The previous operator, when it deploys the CAMARA QoD Provisioning API will set that CR field to `RUNNING`.
+
+Then, you can proceed to create a CFS Service, which will incorporate the just created RFS Service. More information is available at: [Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice](../../service_design/examples/calculator_crd_aas/calculator_crd_aas.md). To create the CFS Service characteristics, you may use the Service Specification available at `/QoDProvisioningAPI/OSLArtifacts/CAMARAaaS-QoD-Provisioning-API-CFS-Specification.json`. You may manually create the CFS Service, or you may onboard this Service Specification by making a POST request to `{{url}}/tmf-api/serviceCatalogManagement/v4/serviceSpecification`.
+
+After creating the Service Specification, you should mark this Service as a Bundle. Then, go to “Service Specification Relationships†and add the RFS Service.
+
+Regarding the LCM Rules for the CFS Service, you should configure the following ones:
+
+**[Pre-Provision Rule] - Forwards the user input towards the created CR of type "CAMARAaaS-QoDProvisiongAPI"**
+
+
+
+<details>
+<summary>Pre-Provision Rule Java code</summary>
+
+```java
+{
+java.util.HashMap<String,String> charvals = new java.util.HashMap<>();
+charvals.put("_CR_SPEC",String.format("""
+apiVersion: org.etsi.osl/v1
+kind: CAMARAaaS-QoDProvisiongAPI
+metadata:
+ name: _to_be_replaced_by_osl_
+spec:
+ messageBroker:
+ address: "%s"
+ port: %d
+ username: "%s"
+ password: "%s"
+ serviceUnderControl:
+ uuid: "%s"
+"""
+, getCharValAsString("messageBroker.address"), getCharValNumber("messageBroker.port"), getCharValAsString("messageBroker.username"), getCharValAsString("messageBroker.password"), getCharValAsString("serviceUnderControl.uuid")));
+setServiceRefCharacteristicsValues("CAMARAaaS - QoD Provisioning API - RFS", charvals);
+}
+```
+
+</details>
+
+
+**[Supervision Rule] - Updates the exposed QoD Provisioning API Service with information about the undertaken actions**
+
+
+
+<details>
+<summary>Supervision Rule Java code</summary>
+
+```java
+{
+java.util.HashMap<String,String> charvals = new java.util.HashMap<>();
+charvals.put("_CR_SPEC",String.format("""
+apiVersion: org.etsi.osl/v1
+kind: CAMARAaaS-QoDProvisiongAPI
+metadata:
+ name: _to_be_replaced_by_osl_
+spec:
+ messageBroker:
+ address: "%s"
+ port: %d
+ username: "%s"
+ password: "%s"
+ serviceUnderControl:
+ uuid: "%s"
+"""
+, getCharValAsString("messageBroker.address"), getCharValNumber("messageBroker.port"), getCharValAsString("messageBroker.username"), getCharValAsString("messageBroker.password"), getCharValAsString("serviceUnderControl.uuid")));
+setServiceRefCharacteristicsValues("CAMARAaaS - QoD Provisioning API - RFS", charvals);
+}
+setCharValFromStringType("camaraAPI.status", getServiceRefPropValue("CAMARAaaS - QoD Provisioning API - RFS", "serviceCharacteristicValue", "spec.camaraAPI.status"));
+setCharValFromStringType("camaraAPI.url", getServiceRefPropValue("CAMARAaaS - QoD Provisioning API - RFS", "serviceCharacteristicValue", "spec.camaraAPI.url"));
+setCharValFromStringType("camaraAPI.username", getServiceRefPropValue("CAMARAaaS - QoD Provisioning API - RFS", "serviceCharacteristicValue", "spec.camaraAPI.username"));
+setCharValFromStringType("camaraAPI.password", getServiceRefPropValue("CAMARAaaS - QoD Provisioning API - RFS", "serviceCharacteristicValue", "spec.camaraAPI.password"));
+setCharValFromStringType("camaraAPI.results", getServiceRefPropValue("CAMARAaaS - QoD Provisioning API - RFS", "serviceCharacteristicValue", "spec.camaraAPI.results"));
+
+```
+</details>
+
+
+You can find the `_CR_SPEC` template used for both rules at `/QoDProvisioningAPI/OSLArtifacts/cr-template.yaml`.
+
+After that, you may expose this service via OSL’s Service Catalog, and order it. When you order it, you will be prompted to configure some characteristics:
+
+- *messageBroker.address*
+- *messageBroker.port*
+- *messageBroker.username*
+- *messageBroker.password*
+- *serviceUnderControl.uuid*
+
+In `serviceUnderControl.uuid` you should input the UUID of the Service (in the Service Inventory) that you ordered before: the one that relates with the Dummy Operator. For this tutorial, we have used the following characteristic values:
+
+
+
+
+Confirm that the service order was completed, both RFS and CFS Services are active, and a Custom Resource of type CAMARAaaS-QoDProvisiongAPI was created in your Kubernetes Cluster. See images below (`kubectl describe camaraaas-qod-provisioning-apis <name> -n <namespace>`)
+
+
+
+
+
+Additionally, in OSL, you may see the URL where the QoD Provisioning API is exposed. To do so, please see the characteristics of the CAMARAaaS QoD Provisioning API CFS. See image below:
+
+
+
+### 3. Validation
+
+Now we can test if the two services are communicating. To do so, you should create a QoD Provisioning via the API that was just deployed. You may do that, using this command:
+
+```bash
+# You must update the url to correspond to your API instance, found in camaraAPI.url highlighted in previous image.
+curl --location '{{camaraAPI.url}}/device-qos' \
+--header 'Content-Type: application/json' \
+--data-raw '{
+ "device": {
+ "phoneNumber": "+987654321",
+ "networkAccessIdentifier": "987654321@example.org",
+ "ipv4Address": {
+ "publicAddress": "203.0.112.12",
+ "publicPort": 59765
+ },
+ "ipv6Address": "2001:db8:85a3:8d3:1319:8a2e:370:7344"
+ },
+ "qosProfile": "QOS_PROFILE_A",
+ "sink": "https://endpoint.example.com/"
+}'
+```
+
+You should have received a response similar to this one:
+
+```bash
+{"device":{"phoneNumber":"+987654321","networkAccessIdentifier":"987654321@example.org","ipv4Address":{"publicAddress":"203.0.112.12","privateAddress":null,"publicPort":59765},"ipv6Address":"2001:db8:85a3:8d3:1319:8a2e:370:7344"},"qosProfile":"QOS_PROFILE_A","sink":"https://endpoint.example.com/","sinkCredential":{"credentialType":null},"provisioningId":"cb55f9e9-802e-4898-95f5-d1a5a2552483","startedAt":"2024-12-17T15:49:21.995399","status":"REQUESTED","statusInfo":null}
+```
+
+Now, if everything is working properly, the characteristics of the Dummy Operator Service you referenced should have been updated. You should now see these characteristics:
+
+
+
+You may also query the QoD Provisioning API to check the status of your provisioning.
+
+```bash
+curl --location '{{camaraAPI.url}}/device-qos/cb55f9e9-802e-4898-95f5-d1a5a2552483'
+# notice the "provisioningId":"cb55f9e9-802e-4898-95f5-d1a5a2552483" above
+```
+
+If you do so, you will receive the following response:
+
+```bash
+{"device":{"phoneNumber":"+987654321","networkAccessIdentifier":"987654321@example.org","ipv4Address":{"publicAddress":"203.0.112.12","privateAddress":null,"publicPort":59765},"ipv6Address":"2001:db8:85a3:8d3:1319:8a2e:370:7344"},"qosProfile":"QOS_PROFILE_A","sink":"https://endpoint.example.com/","sinkCredential":{"credentialType":null},"provisioningId":"cb55f9e9-802e-4898-95f5-d1a5a2552483","startedAt":"2024-12-17T15:49:21.962746","status":"REQUESTED","statusInfo":null}
+```
+
+As there is no logic behind the Dummy Operator Service, the provisioning will remain with the status “REQUESTEDâ€. However, we can simulate that Dummy Operator Service enforced a QOS enforcement, by patching its Custom Resource:
+
+```bash
+kubectl patch dummy-operator-services <name> -n <namespace> \
+--type='json' -p='[{"op": "replace", "path": "/spec/camaraResults", "value": "[{\"device\": {\"ipv4Address\": {\"publicAddress\": \"203.0.112.12\", \"publicPort\": 59765}, \"ipv6Address\": \"2001:db8:85a3:8d3:1319:8a2e:370:7344\", \"networkAccessIdentifier\": \"987654321@example.org\", \"phoneNumber\": \"+987654321\"}, \"provisioningId\": \"cb55f9e9-802e-4898-95f5-d1a5a2552483\", \"qosProfile\": \"QOS_PROFILE_A\", \"sink\": \"https://endpoint.example.com/\", \"sinkCredential\": {}, \"status\": \"AVAILABLE\", \"startedAt\": \"2024-12-15T11:00:00Z\"}]"}]'
+```
+
+When you do this, the `camaraResults` characteristic in the Dummy Operator Service will be updated to:
+
+
+
+After a while, if you check the characteristics of the CAMARAaaS QoD Provisioning API CFS, you will also see that the characteristic `camaraAPI.results` was updated.
+
+
+
+Finally, execute this request again:
+
+```bash
+curl --location '{{camaraAPI.url}}/device-qos/cb55f9e9-802e-4898-95f5-d1a5a2552483'
+# notice the "provisioningId":"cb55f9e9-802e-4898-95f5-d1a5a2552483" above
+```
+
+You should receive the following response.
+
+```bash
+{"device":{"phoneNumber":"+987654321","networkAccessIdentifier":"987654321@example.org","ipv4Address":{"publicAddress":"203.0.112.12","privateAddress":null,"publicPort":59765},"ipv6Address":"2001:db8:85a3:8d3:1319:8a2e:370:7344"},"qosProfile":"QOS_PROFILE_A","sink":"https://endpoint.example.com/","sinkCredential":{"credentialType":null},"provisioningId":"cb55f9e9-802e-4898-95f5-d1a5a2552483","startedAt":"2024-12-15T11:00:00","status":"AVAILABLE","statusInfo":null}
+```
+
+Notice the `"status":"AVAILABLE"`. This means the 2 services are communicating.
+
+
+Now, you just have to implement your own Kubernetes Operator for your 5G Core configuration, and you may use OSL’s CAMARAaaS Add-on to expose it through a CAMARA API.
\ No newline at end of file
diff --git a/doc/addons/intro.md b/doc/addons/intro.md
new file mode 100644
index 0000000000000000000000000000000000000000..03401b2a79a40aac25a9010396dea3862b52d912
--- /dev/null
+++ b/doc/addons/intro.md
@@ -0,0 +1,7 @@
+# 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
diff --git a/doc/architecture/cridge/cridge_introduction.md b/doc/architecture/cridge.md
similarity index 95%
rename from doc/architecture/cridge/cridge_introduction.md
rename to doc/architecture/cridge.md
index 2866d16627516a24bca32c92b948bfb5dec46c29..6ca1065f208152725997fbbf3cb250278edd83b6 100644
--- a/doc/architecture/cridge/cridge_introduction.md
+++ b/doc/architecture/cridge.md
@@ -41,7 +41,7 @@ Pros, in a nutshell:
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. The OSL Orchestrator (OSOM) will manage the lifecycle of the Service Order.
@@ -52,7 +52,7 @@ The following image illustrates the approach.
-
+
@@ -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:
-
+
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:
-
+
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:
-
+
- 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)
diff --git a/doc/architecture/cridge/img01.png b/doc/architecture/images/cridge/img01.png
similarity index 100%
rename from doc/architecture/cridge/img01.png
rename to doc/architecture/images/cridge/img01.png
diff --git a/doc/architecture/cridge/img02.png b/doc/architecture/images/cridge/img02.png
similarity index 100%
rename from doc/architecture/cridge/img02.png
rename to doc/architecture/images/cridge/img02.png
diff --git a/doc/architecture/cridge/img03.png b/doc/architecture/images/cridge/img03.png
similarity index 100%
rename from doc/architecture/cridge/img03.png
rename to doc/architecture/images/cridge/img03.png
diff --git a/doc/architecture/cridge/img04.png b/doc/architecture/images/cridge/img04.png
similarity index 100%
rename from doc/architecture/cridge/img04.png
rename to doc/architecture/images/cridge/img04.png
diff --git a/doc/architecture/cridge/img05.png b/doc/architecture/images/cridge/img05.png
similarity index 100%
rename from doc/architecture/cridge/img05.png
rename to doc/architecture/images/cridge/img05.png
diff --git a/doc/architecture/images/metrico/metrico_arch_introduction.png b/doc/architecture/images/metrico/metrico_arch_introduction.png
new file mode 100644
index 0000000000000000000000000000000000000000..8dff6c9177a8af34583b9f7b60bc908bfa4ea461
Binary files /dev/null and b/doc/architecture/images/metrico/metrico_arch_introduction.png differ
diff --git a/doc/architecture/images/metrico/metrico_service_sequence_diagram.png b/doc/architecture/images/metrico/metrico_service_sequence_diagram.png
new file mode 100644
index 0000000000000000000000000000000000000000..2a701df9e9c26d012d62240668ac339c919dd4d7
Binary files /dev/null and b/doc/architecture/images/metrico/metrico_service_sequence_diagram.png differ
diff --git a/doc/architecture/messagebus.md b/doc/architecture/messagebus.md
index a228afb52670b03e7036a2199cbfecd1454a2d50..e1ceeb7e3e261f7e57214cf1d271fce38db0ab63 100644
--- a/doc/architecture/messagebus.md
+++ b/doc/architecture/messagebus.md
@@ -1,8 +1,8 @@
# 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.
diff --git a/doc/architecture/metrico.md b/doc/architecture/metrico.md
new file mode 100644
index 0000000000000000000000000000000000000000..9011e6ce01d55dd39176351ead3857f77d58bda8
--- /dev/null
+++ b/doc/architecture/metrico.md
@@ -0,0 +1,39 @@
+
+# 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:
+
+
+
+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.
+
+
+
+## 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)
+
diff --git a/doc/architecture/nfvapi.md b/doc/architecture/nfvapi.md
index f31f195812fda0c41cf8165c5448c32a4931884c..14558621280072ef661e749beb331cc7697224f5 100644
--- a/doc/architecture/nfvapi.md
+++ b/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,
diff --git a/doc/architecture/oauth.md b/doc/architecture/oauth.md
index 049c4e56eff0e3dea31b74e059dca870f92be8b9..e7081a7b093089d61d972208a7230cb1ece642c3 100644
--- a/doc/architecture/oauth.md
+++ b/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
+```
diff --git a/doc/architecture/tmfapi.md b/doc/architecture/tmfapi.md
index 5b93ade5255eda26b4b99b7712725a57f767af69..168efa29df14ac3c17a01f1e6b94c1801fef814c 100644
--- a/doc/architecture/tmfapi.md
+++ b/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",
diff --git a/doc/contributing/developing.md b/doc/contribute/developing.md
similarity index 99%
rename from doc/contributing/developing.md
rename to doc/contribute/developing.md
index 432e5b003f0fad621b8ac3c4fb9a5da4efb98afc..fa8e17b52856f6d1d90a3ef9989c0be5d0c0b61e 100644
--- a/doc/contributing/developing.md
+++ b/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
diff --git a/doc/contribute/documenting.md b/doc/contribute/documenting.md
new file mode 100644
index 0000000000000000000000000000000000000000..84cb8aaeecd8b8304c4b1352bbb50516d9b558e6
--- /dev/null
+++ b/doc/contribute/documenting.md
@@ -0,0 +1,80 @@
+# Documenting
+
+OpenSlice's documentation runs on [MkDocs](https://www.mkdocs.org/).
+
+## Eligibility
+
+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!
+
+## 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 these easy steps:
+
+1) Clone the [Documentation repository](https://labs.etsi.org/rep/osl/documentation) with:
+
+```bash
+git clone https://labs.etsi.org/rep/osl/documentation.git
+```
+
+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 with a virtual environment:
+
+=== "Linux + macOS"
+
+ ``` bash
+ python3 -m venv venv
+ source venv/bin/activate
+ ```
+
+=== "Windows"
+
+ ``` bash
+ python -m venv venv
+ venv\Scripts\activate
+ ```
+
+``` bash
+python -m pip install -r requirements.txt
+```
+
+4) Wait for all downloads to finish and start the local ``mkdocs`` server:
+
+```bash
+mkdocs serve
+```
+
+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.
+
+## Learn more
+
+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
diff --git a/doc/contributing/wishlist.md b/doc/contribute/wishlist.md
similarity index 100%
rename from doc/contributing/wishlist.md
rename to doc/contribute/wishlist.md
diff --git a/doc/contributing/documenting.md b/doc/contributing/documenting.md
deleted file mode 100644
index f5a14e5b53dbf459891da5816b29d4854a255e06..0000000000000000000000000000000000000000
--- a/doc/contributing/documenting.md
+++ /dev/null
@@ -1,78 +0,0 @@
-
-# Documenting
-
-OpenSlice's documentation runs on [MkDocs](https://www.mkdocs.org/).
-
-## Eligibility
-
-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
-
-[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:
-
-1) Clone the [Documentation repository](https://labs.etsi.org/rep/osl/documentation) with:
-
-```bash
-git clone https://labs.etsi.org/rep/osl/documentation.git
-```
-
-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
-
-=== "Linux + macOS"
-
- ``` bash
- 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"
-
- ``` bash
- 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
- ```
-
-
-4) Wait for all downloads to finish and start the mkdocs server
-
-```bash
-mkdocs serve
-```
-
-5) Document (and commit)! 😊
-
-Before committing, you should make sure that the local mkdcocs server's terminal is not producing any INFO/WARNING message regarding your contributions.
-
-> 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.
diff --git a/doc/getting_started/deployment/docker_compose.md b/doc/getting_started/deployment/docker_compose.md
index b7d917f069d02ac5c9f94e82b21496692900c0ff..31ef05f70382ae2df76891b4e7a88bf0fb1cecbf 100644
--- a/doc/getting_started/deployment/docker_compose.md
+++ b/doc/getting_started/deployment/docker_compose.md
@@ -89,7 +89,7 @@ We recommend:
* develop branch for an experience with the latest features (for develop branch installation, it is strongly advisable that you may as well follow the [develop documentation](https://osl.etsi.org/documentation/develop/))
```bash
-sudo ./deploy.sh main #[or replace main with other branch name]
+sudo ./deploy.sh main #[or replace main with develop or other branch name]
```
> **We recommend running the deploy.sh script with root permissions! In other case, some directories may not be accessible by the project building tools and hinder the smooth installation.**
@@ -390,7 +390,7 @@ cd org.etsi.osl.main/compose/
```
```bash
-sudo docker compose --profile prod down;sudo docker compose --profile prod up -d --build
+sudo docker compose --profile prod down;sudo docker compose --profile prod up -d
```
> Depending on your machine, this process might take time. if for any reason the deployment fails during first time, please rerun the above before any further measures.
diff --git a/doc/index.md b/doc/index.md
index 198cf6593a71573d949c24ee805afbcdcd677543..f2f32772fbbb9790f2e646dde31e50b69eaf6777 100644
--- a/doc/index.md
+++ b/doc/index.md
@@ -3,7 +3,7 @@
<img src="images/openslice_logo.png" alt="logo" width="200"/>
-**Version**: {{{ documentation_version }}} ([Release Notes](https://labs.etsi.org/rep/osl/code/org.etsi.osl.main/-/releases/{{{ documentation_version }}}))
+**Version**: {{{ documentation_version }}} ([Release Notes](https://labs.etsi.org/rep/osl/code/org.etsi.osl.main/-/releases))
The ETSI Software Development Group for OpenSlice (SDG OSL) is developing an open-source service-based Operations Support System (OSS) to deliver Network as a Service (NaaS) following specifications from major SDOs including ETSI, TM Forum and GSMA.
diff --git a/doc/service_design/examples/calculator_crd_aas/calculator_crd_aas.md b/doc/service_design/examples/calculator_crd_aas/calculator_crd_aas.md
index f2c0f52c71a86ee872303e0acd7e7030f213c1d0..ef06fa565d15f843e3ed5bb58d723edd8fe8fe05 100644
--- a/doc/service_design/examples/calculator_crd_aas/calculator_crd_aas.md
+++ b/doc/service_design/examples/calculator_crd_aas/calculator_crd_aas.md
@@ -1,5 +1,5 @@
-# Exposing Kubernetes Operators as a Service : Offering "Calculator as a Service" through OpenSlice
+# Exposing Kubernetes Operators as-a-Service: Offering "Calculator as-a-Service"
**Intended Audience: OpenSlice Service Designers**
diff --git a/doc/service_design/examples/jenkins_helm_install_aas/jenkins_helm_install_aas.md b/doc/service_design/examples/jenkins_helm_install_aas/jenkins_helm_install_aas.md
index dae3315444d107f8acf7056c59731234a7c44610..34710dfa9f9d40385d13e69b1240b48747f7598d 100644
--- a/doc/service_design/examples/jenkins_helm_install_aas/jenkins_helm_install_aas.md
+++ b/doc/service_design/examples/jenkins_helm_install_aas/jenkins_helm_install_aas.md
@@ -1,4 +1,6 @@
-# Example: Offer Jenkins as a Service via Openslice
+# Example: Offer Jenkins (Helm Chart) as-a-Service
+
+**Intended Audience: OpenSlice Service Designers**
## Design the Jenkins (Resource-Facing) Service
diff --git a/doc/service_design/examples/monitoring_aas/images/edit_cfs_service_characteristic.png b/doc/service_design/examples/monitoring_aas/images/edit_cfs_service_characteristic.png
new file mode 100644
index 0000000000000000000000000000000000000000..0eceed28796facb4016261e20307887c76a1369c
Binary files /dev/null and b/doc/service_design/examples/monitoring_aas/images/edit_cfs_service_characteristic.png differ
diff --git a/doc/service_design/examples/monitoring_aas/images/exposed_metrico_cfss.png b/doc/service_design/examples/monitoring_aas/images/exposed_metrico_cfss.png
new file mode 100644
index 0000000000000000000000000000000000000000..d78548d68fdde823dcac9d158f0423484781ef86
Binary files /dev/null and b/doc/service_design/examples/monitoring_aas/images/exposed_metrico_cfss.png differ
diff --git a/doc/service_design/examples/monitoring_aas/images/metrico_cfss.png b/doc/service_design/examples/monitoring_aas/images/metrico_cfss.png
new file mode 100644
index 0000000000000000000000000000000000000000..4c1d72e116b7cfc486ddf503d82b6f3d111f4375
Binary files /dev/null and b/doc/service_design/examples/monitoring_aas/images/metrico_cfss.png differ
diff --git a/doc/service_design/examples/monitoring_aas/images/metrico_cfss_characteristics.png b/doc/service_design/examples/monitoring_aas/images/metrico_cfss_characteristics.png
new file mode 100644
index 0000000000000000000000000000000000000000..a5685d0d9515f56fd0df5554bf5ee5da6e73f55e
Binary files /dev/null and b/doc/service_design/examples/monitoring_aas/images/metrico_cfss_characteristics.png differ
diff --git a/doc/service_design/examples/monitoring_aas/images/metrico_cfss_creation_rule.png b/doc/service_design/examples/monitoring_aas/images/metrico_cfss_creation_rule.png
new file mode 100644
index 0000000000000000000000000000000000000000..c88121b1fb9cc9a589b7fb9c4507b946817dae61
Binary files /dev/null and b/doc/service_design/examples/monitoring_aas/images/metrico_cfss_creation_rule.png differ
diff --git a/doc/service_design/examples/monitoring_aas/images/metrico_cfss_order_checkout.png b/doc/service_design/examples/monitoring_aas/images/metrico_cfss_order_checkout.png
new file mode 100644
index 0000000000000000000000000000000000000000..cf34ce24f50fbdd91fa10c39c008edcbcbea2a2b
Binary files /dev/null and b/doc/service_design/examples/monitoring_aas/images/metrico_cfss_order_checkout.png differ
diff --git a/doc/service_design/examples/monitoring_aas/images/metrico_cfss_order_completed.png b/doc/service_design/examples/monitoring_aas/images/metrico_cfss_order_completed.png
new file mode 100644
index 0000000000000000000000000000000000000000..0a350cb1b867d2330cea458940dae35f3773868a
Binary files /dev/null and b/doc/service_design/examples/monitoring_aas/images/metrico_cfss_order_completed.png differ
diff --git a/doc/service_design/examples/monitoring_aas/images/metrico_cfss_order_processing.png b/doc/service_design/examples/monitoring_aas/images/metrico_cfss_order_processing.png
new file mode 100644
index 0000000000000000000000000000000000000000..0640c31241ae7fd6028bbbd938c4c97c471df67c
Binary files /dev/null and b/doc/service_design/examples/monitoring_aas/images/metrico_cfss_order_processing.png differ
diff --git a/doc/service_design/examples/monitoring_aas/images/metrico_retrieved_monitoring_data.png b/doc/service_design/examples/monitoring_aas/images/metrico_retrieved_monitoring_data.png
new file mode 100644
index 0000000000000000000000000000000000000000..2ca78a1196b22273bb72ed8162c3a7a62b6644d1
Binary files /dev/null and b/doc/service_design/examples/monitoring_aas/images/metrico_retrieved_monitoring_data.png differ
diff --git a/doc/service_design/examples/monitoring_aas/images/metrico_rfss.png b/doc/service_design/examples/monitoring_aas/images/metrico_rfss.png
new file mode 100644
index 0000000000000000000000000000000000000000..c4482e08ed8726afcad4520cd8aead275b4d878c
Binary files /dev/null and b/doc/service_design/examples/monitoring_aas/images/metrico_rfss.png differ
diff --git a/doc/service_design/examples/monitoring_aas/monitoring_aas.md b/doc/service_design/examples/monitoring_aas/monitoring_aas.md
new file mode 100644
index 0000000000000000000000000000000000000000..639959ce706c16a407e659645a760de6bfb18152
--- /dev/null
+++ b/doc/service_design/examples/monitoring_aas/monitoring_aas.md
@@ -0,0 +1,135 @@
+# Example: Integrate Prometheus monitoring solution as-a-Service
+
+**Intended Audience: OpenSlice Service Designers**
+
+## Design the Monitoring (Resource-Facing) Service
+
+<!-- Before reading this example please make sure that you went through the [Design Helm as a Service](../../kubernetes/design_helm_aas.md) -->
+
+In this example, we will use the ```METRICO_Resource_Specification``` that the METRICO component exposes upon instantiation and create a ResourceFacingServiceSpecification (RFSS) to integrate data from a Prometheus instance.
+
+1. Navigate to Service Specifications
+2. Create New Specification
+3. Provide a Name, eg. Metrico RFS
+4. Navigate to Resource Specification Relationships
+5. Assign **METRICO_Resource_Specification** as a related Resource Specification
+
+
+
+
+At this step, someone can focus on the Characteristics' configuration of the RFSS to define the desired functionality of the monitoring job. If you want to create a RFSS that executes a well-defined, static monitoring task (source, query, interval etc), you may navigate at the Characteristic's tab and assign default values to the respective characteristics.
+
+Although, if you want the user to be able to dynamically define its monitoring task through a single designed service, please continue with this guide.
+
+For reference, the available Characteristics are:
+
+- **_MT_TYPE**: The monitoring source type (default value: PROMETHEUS)
+- **_MT_URL**: The monitoring source URL (e.g. https://prom.osl.etsi.org:9090)
+- **_MT_QUERY**: The query towards the monitoring source (e.g. query=gnb_service_state)
+- **_MT_RECURRING_INTERVAL**: The polling interval of the monitoring source (default value: G_1MN, Available values: G_10SEC, G_30SEC, G_1MN, G_5MN, G_15MN, G_30MN, G_1H, G_24H, G_1M, G_1Y)
+- **_MT_START_TIME**: The starting time of the monitoring job (default value, if left blank: NOW)
+- **_MT_END_TIME**: The ending time of the monitoring job (default value, if left blank: NOW + 1h)
+- **_MT_SERVICEUUID**: The ID of the service to update with the retrieved monitoring data
+- **_MT_CHARACTERISTIC_NAME**: The characteristic of the service with id _MT_SERVICEUUID that will be updated with the retrieved monitoring data
+
+
+## Expose the Monitoring (Customer-Facing) Service to the Users
+
+To expose the monitoring service towards the users, the designer must create the respective CustomerFacingServiceSpecification (CFSS), by using the previously designed RFSS as a related service.
+
+ 1. Navigate to Service Specifications
+ 2. Create New Specification
+ 3. Provide a Name, e.g. Metrico Service, mark as Bundle (to enable Service Specification Relationships) and save it
+ 4. Navigate to the "Service Specification Relationships" tab and assign Metrico RFS
+ 5. (Optionally) Add a logo, from the respective "Logo" tab
+
+
+
+At this stage, if you opted for the design of a dynamic, user-adjustable monitoring service, you must define the Characteristic(s) that will be exposed to the user. For this, you must navigate to the "Service Specification Characteristics" tab.
+
+Specifically, you have to choose which Characteristics (from the ones introduced above) a user can edit and provide default values for the ones you opt out. In our example, we will design as if all the Characteristics are exposable to the user.
+
+Using "Create New Characteristic" menu, create the Characteristics as shown below:
+
+- Provide a name (e.g. _MT_TYPE)
+- Provide a description for the user (optional)
+- ValueType: TEXT
+- Configurable: true (if you want the user to be able to change it)
+- Service Characteristic Value (optional) - Value (e.g. PROMETHEUS)
+- Service Characteristic Value (optional) - Is Default: true
+
+> Note 1: You are not obliged to follow the same Characteristic names with the RFSS. The example does that for better clarity.
+
+> Note 2: Defining Service Characteristic Value is optional. But if you opt for a Characteristic to be non-configurable, you have to define a default value.
+
+After filling all the Characteristics, you should be able to see something like the image below:
+
+
+
+The above configuration is expected to query ```http://172.16.10.100:9090/api/v1/query?query=gnb_service_state&time=1736528808.484``` every 1 minute and return the result to the service that the user will point out (filling ```_MT_SERVICEUUID ```), and especially into a Characteristic named ```METRICO Result```.
+
+In our presented example, we would like the monitoring service to wait for user input for the ```_MT_SERVICEUUID```, before starting. The user can either provide this during the Service Order (if it is already known and available at the Service Inventory), or add it during execution.
+
+To achieve the above, you should navigate to the "Life Cycle Rules" tab and create a Creation Rule that will prevent the Metrico RFS from starting, unless the ```_MT_SERVICEUUID``` is provided. Also, you have to pass the updated user-defined Characteristics from the current to the Metrico RFS, when the previous condition is met. To do so, the rule has to be as the following:
+
+
+
+Let's create it step-by-step:
+
+- Drag-and-drop the Create string variable block (from Text blocks)
+- Click the drop-down menu, Rename variable... and input "consumingServiceId"
+- Select the Get Value as String block (from Service > Characteristics blocks), opt for "_MT_SERVICEUUID" from the drop-down menu and attach to the previous block
+- Select the Conditionally Create Ref Service block (from Service > Relationships > Service Refs blocks)
+- At its first slot, attach the Metrico RFS block (from Service > Relationships > Service Refs blocks)
+- At the second slot, attach sequentially a) the Not and b) the String Comparison blocks (from Logic blocks)
+- The Comparison block must compare the "consumingServiceId" variable value (From Text blocks) and an empty line of text (From Text blocks)
+- At the final slot, attach the Create list block (from Lists blocks)
+- From the last block's gear button, drag-and-drop more items in the list (must be 8, as the Characteristics)
+- At each list item, attach the Set values to characteristics of a referenced service block (Service > Relationships > Service Refs blocks)
+- Each block must have the RFS's Characteristic Name (fill it in at a line of text block) and the respective Tvalue from the Get Value as String block (from Service > Characteristics blocks)
+- Repeat for every characteristic, as shown above
+- Change the "lifecycle phase" drop-down option to "CREATION"
+
+The design phase is not completed! Finally, you must expose the created Metrico CFSS through an already created Service Catalog and Service Category so as to make it visible to the users, thus available for ordering.
+
+
+
+
+## Order the Metrico Service
+
+Order the service from the previously assigned Service Catalog > Service Category.
+
+Here, we assume that the user will not provide the ```_MT_SERVICEUUID``` during the Service Order Checkout phase, neither the task's interval (which defaults to 1 hour). Note how the values are filled in with the defaults from the designing phase.
+
+
+
+Once ordered, you may navigate to the Order Preview by Manage Services > Service Orders list.
+
+## Order Fulfillment and Monitoring Data Retrieval
+
+The default state of a Service Order is **INITIAL**. Unless not opted differently (via an API call, for instance), this step requires user intervention to change the state to **ACKNOWLEDGED** (via the Edit button).
+
+As soon as the Service Order is in **ACKNOWLEDGED** state, it will be processed and the state will be automatically updated to **INPROGRESS**, as seen in the figure below.
+
+
+
+As defined by the designed Creation Rule, the Service Order is expecting the user to provide the ```_MT_SERVICEUUID```.
+
+Starting from the Service Order overview and specifically the Order Item #1 tab > Supporting Services, select the Metrico Service.
+
+Navigate to the "Service Characteristics" tab and click the edit Service Characteristics button. Provide the ID of the Metrico Service (as found in the address bar), at the ```_MT_SERVICEUUID``` value, as depicted in the figure below.
+
+
+
+Once the ```_MT_SERVICEUUID``` value is provided, the Metrico RFS will be created and eventually the Service Order will become "COMPLETED", as seen in the Service Order overview.
+
+
+
+From this menu, if you navigate once more at the Order Item #1 tab > Supporting Services > Metrico Service, you will be able to see the retrieved monitoring data.
+
+Specifically, the "Service Characteristics" tab now has a new entry, i.e. ```Metrico Results```, with the respective data. The data are updated with the defined interval of 1 minute and every potential change will appear there. At this point, someone can create a "SUPERVISION" rule, which is triggered by changes in Service Characteristics (e.g. ```Metrico Results```), and perform some action based on the monitoring data results.
+
+
+
+
+> The ```_MT_SERVICEUUID``` could have been automatically provided by a Rule, thus minimizing the need for user intervention.
\ No newline at end of file
diff --git a/doc/service_design/kubernetes/exposing_kubernetes_resources.md b/doc/service_design/kubernetes/exposing_kubernetes_resources.md
index 5eba68457f7ffaaa69954de0f81a381bdcfb8c7d..a9d6844e0df3cc8db4ce11cda4b01f9c21df62c7 100644
--- a/doc/service_design/kubernetes/exposing_kubernetes_resources.md
+++ b/doc/service_design/kubernetes/exposing_kubernetes_resources.md
@@ -134,7 +134,7 @@ OpenSlice adds automatically as we see the following characteristics:
- See examples of exposing Kubernetes Operators as a Service via OpenSlice:
- [Offering "Calculator as a Service"](../examples/calculator_crd_aas/calculator_crd_aas.md)
- [Offering "Helm installation as a Service" (Jenkins example)](../examples/jenkins_helm_install_aas/jenkins_helm_install_aas.md)
-- [Learn more about CRIDGE, the service in OpenSlice that manages CRDs/CRs](../../architecture/cridge/cridge_introduction.md)
+- [Learn more about CRIDGE, the service in OpenSlice that manages CRDs/CRs](../../architecture/cridge.md)
diff --git a/doc/service_design/monitoring/design_monitoring_services.md b/doc/service_design/monitoring/design_monitoring_services.md
new file mode 100644
index 0000000000000000000000000000000000000000..2aacd078df181411dc903d65acaa5fc091b15013
--- /dev/null
+++ b/doc/service_design/monitoring/design_monitoring_services.md
@@ -0,0 +1,38 @@
+# Design Monitoring Services
+
+**Intended Audience: OpenSlice Service Designers**
+
+This section introduces a way to design Service Specifications that integrate external monitoring sources (e.g. a Prometheus instance). This type of services require METRICO component running (see more information about METRICO at the [Architecture's section](../../architecture/metrico.md)).
+
+## METRICO Resource Specification
+
+When METRICO component instantiates, it automatically creates a respective Resource Specification, named ```METRICO_Resource_Specification```. It is always noted with a specific ```Version``` and ```Category```. As METRICO evolves, this combination shall change. METRICO creates its versioned Resource Specification, only when it is not already existing.
+
+
+
+The Resource Specification comprises of all the properties needed to execute a monitoring job towards an external source and return the data to a candidate service. For this reason, it incorporates the respective characteristics, as shown below:
+
+
+
+Namely, the characteristics provide the following information:
+
+- **_MT_TYPE**: The monitoring source type (default value: PROMETHEUS)
+- **_MT_URL**: The monitoring source URL (e.g. https://prom.osl.etsi.org:9090)
+- **_MT_QUERY**: The query towards the monitoring source (e.g. query=gnb_service_state)
+- **_MT_RECURRING_INTERVAL**: The polling interval of the monitoring source (default value: G_1MN, Available values: G_10SEC, G_30SEC, G_1MN, G_5MN, G_15MN, G_30MN, G_1H, G_24H, G_1M, G_1Y)
+- **_MT_START_TIME**: The starting time of the monitoring job (default value, if left blank: NOW)
+- **_MT_END_TIME**: The ending time of the monitoring job (default value, if left blank: NOW + 1h)
+- **_MT_SERVICEUUID**: The ID of the service to update with the retrieved monitoring data
+- **_MT_CHARACTERISTIC_NAME**: The characteristic of the service with id _MT_SERVICEUUID that will be updated with the retrieved monitoring data
+
+## METRICO Service Design
+
+If you want to design a Monitoring Service that can be incorporated within other service bundles or directly expose it towards the users, you have to create a new Service Specification and relate the previously mentioned METRICO Resource Specification to it.
+
+
+
+A Service Specification which is related to a Resource Specification is switched to a Resource Facing Service Specification (RFSS) and the Resource Characteristics are copied to the RFSS. At that stage, the Service Designer needs to fill in the Characteristics's default values and/or enable the user to provide its preferences through service bundles.
+
+## Probe further
+
+See the [Example: Integrate Prometheus monitoring solution as-a-Service](../examples/monitoring_aas/monitoring_aas.md).
\ No newline at end of file
diff --git a/doc/service_design/monitoring/images/MetricoResourceSpecification.png b/doc/service_design/monitoring/images/MetricoResourceSpecification.png
new file mode 100644
index 0000000000000000000000000000000000000000..dd01fc4193221446e7270d490f385b28ed932a15
Binary files /dev/null and b/doc/service_design/monitoring/images/MetricoResourceSpecification.png differ
diff --git a/doc/service_design/monitoring/images/MetricoResourceSpecificationCharacteristics.png b/doc/service_design/monitoring/images/MetricoResourceSpecificationCharacteristics.png
new file mode 100644
index 0000000000000000000000000000000000000000..c4c603c18138a87fcb96298c0c03d3b8828a2f74
Binary files /dev/null and b/doc/service_design/monitoring/images/MetricoResourceSpecificationCharacteristics.png differ
diff --git a/doc/service_design/monitoring/images/MonitoringServiceDesign.png b/doc/service_design/monitoring/images/MonitoringServiceDesign.png
new file mode 100644
index 0000000000000000000000000000000000000000..f554f57c125137faaa38b4774118357d5d0e9146
Binary files /dev/null and b/doc/service_design/monitoring/images/MonitoringServiceDesign.png differ
diff --git a/doc/service_design/nfv/design_nfv_services.md b/doc/service_design/nfv/design_nfv_services.md
index 7cb056684848e7b85ae0cc480b6fcf5d414ca1e6..f6008dcb215e8f1ef617008cce293c004637c3a2 100644
--- a/doc/service_design/nfv/design_nfv_services.md
+++ b/doc/service_design/nfv/design_nfv_services.md
@@ -1,4 +1,4 @@
-# Design NFV services
+# Design NFV Services
**Intended Audience: OpenSlice Service Designers**
diff --git a/mkdocs.yml b/mkdocs.yml
index a40ae000685f0e2e08ecfb0cf692ee778cb7da6c..a14dbaccaebebc96b13ce5aa5d07aa489f75654c 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -99,7 +99,7 @@ extra:
link: https://twitter.com/OpensliceOSS
version:
provider: mike
- documentation_version: "2024Q4"
+ documentation_version: "develop"
# Page tree
nav:
@@ -152,6 +152,8 @@ nav:
- Design Helm as a Service: ./service_design/kubernetes/design_helm_aas.md
- Support for NFV:
- Design NFV Services: ./service_design/nfv/design_nfv_services.md
+ - Support for Monitoring:
+ - Design Monitoring Services: ./service_design/monitoring/design_monitoring_services.md
- LCM Rules:
- Introduction: ./service_design/lcmrules/intro.md
- Specification: ./service_design/lcmrules/specification.md
@@ -162,6 +164,7 @@ nav:
# - Open5GS (Kubernetes approach): ./service_design/examples/open5gs_kubernetes.md
- Calculator CRD aaS: ./service_design/examples/calculator_crd_aas/calculator_crd_aas.md
- Jenkins Helm Installation aaS : ./service_design/examples/jenkins_helm_install_aas/jenkins_helm_install_aas.md
+ - Monitoring aaS: ./service_design/examples/monitoring_aas/monitoring_aas.md
- Service Ordering:
- Ordering Services from catalogs: ./service_ordering/ordering_services.md
# - Testing services:
@@ -175,18 +178,24 @@ nav:
# - Assurance services:
# - Introduction: ./assurance_services/intro.md
# - Alarms and Actions: ./assurance_services/alarms_actions.md
+ - Addons:
+ - Introduction: ./addons/intro.md
+ - CAMARA:
+ - Offering CAMARAaaS: ./addons/camara/intro.md
+ - Quality on Demand: ./addons/camara/qod.md
- Design & Architecture:
- Architecture: ./architecture/architecture.md
- - CRIDGE: ./architecture/cridge/cridge_introduction.md
- Message bus: ./architecture/messagebus.md
- OSOM: ./architecture/osom.md
+ - CRIDGE: ./architecture/cridge.md
+ - METRICO: ./architecture/metrico.md
- Authentication: ./architecture/oauth.md
- APIs:
- TMF API: ./architecture/tmfapi.md
- NFV API: ./architecture/nfvapi.md
- Issue management: ./architecture/issuemgt.md
- Central logging: ./architecture/centrallog.md
- - Contributing to OSL:
- - Developing: ./contributing/developing.md
- - Documenting: ./contributing/documenting.md
+ - Contribute:
+ - Developing: ./contribute/developing.md
+ - Documenting: ./contribute/documenting.md
- Terminology: terminology.md
diff --git a/requirements.txt b/requirements.txt
new file mode 100644
index 0000000000000000000000000000000000000000..10a0c2fe3f8d351a9e4307e156a2f6e21d2141cb
--- /dev/null
+++ b/requirements.txt
@@ -0,0 +1,5 @@
+mkdocs
+mkdocs-material
+mkdocs-glightbox
+mkdocs-markdownextradata-plugin
+mike
\ No newline at end of file