Merge branch 'develop' into 'main'

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).

To replicate this PoC you have to clone 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

# LF Sylva Addon

## Introduction

Sylva, a project under the Linux Foundation, is designed to meet the unique demands of the telecom and edge cloud sectors. As telecommunications (telco) networks increasingly transition toward edge computing environments, Sylva provides a tailored cloud software framework for these specialized needs. It does not only address technical challenges in this domain, but also provides a reference implementation of the framework, which can be validated against industry requirements.

The primary goal of Sylva is to ensure that telecom operators have a reliable, flexible, and scalable cloud infrastructure that supports the edge computing needs of modern networks. Additionally, Sylva aims to create a validation program for these implementations, ensuring that they meet the evolving standards and demands of the industry. You can read more about Sylva [here](https://sylvaproject.org/).

## OSL Sylva Addon

The synergy between OSL and Sylva offers a powerful combination that addresses the increasing complexity of managing telco and edge cloud infrastructures. We developed an Addon operator that enables the integration of OSL and Sylva, thus optimizing service orchestration and resource management for telecom operators. This is demonstrated through new resource operators that OSL developed as extensions. 

These operators allow OSL tenants to request and manage Sylva workload clusters directly through OSL’s platform and TMF APIs. This capability means that tenants can now order Kubernetes clusters managed by Sylva in a self-service manner, simplifying resource allocation and management. 

The integration of Sylva with OSL leverages TMF APIs to expose and manage Sylva’s telco-focused cloud software framework. By doing so, OSL provides an efficient means of ordering and orchestrating Sylva’s resources within the broader context of network services.

The collaboration between OSL and Sylva highlights several key advantages for telecom operators, including:

- **Self-Service Resource Management**: OSL tenants can seamlessly request and manage Sylva workloads, providing greater flexibility and speed in resource provisioning.

- **Streamlined Orchestration**: By utilizing TMF APIs, OSL simplifies the process of requesting and managing Sylva clusters, reducing the complexity of managing edge cloud infrastructure.

- **Scalability and Flexibility**: Sylva’s cloud framework is built specifically for the telco industry, offering scalability and flexibility for telecom operators looking to expand their edge computing capabilities.

- **Efficiency and Automation**: The integration enables automated resource provisioning and lifecycle management, ensuring that telecom operators can focus on innovation rather than manual resource management.

We explored the following aspects, which are also represented visually in the following figure:

1. **Identity and Access Management**: This setup uses Keycloak for Identity and Access Management (IAM). Both OSL (installed in an OSL management cluster) and Sylva’s services (Sylva services installed in management cluster) interact with Keycloak to authenticate and authorize users or services, ensuring secure access to resources. This step is crucial for managing user permissions, access rights, and the security of operations.

2. **Request Workload Clusters**: The **OSL Management Cluster** interfaces with the **Sylva Management Cluster** to request workload clusters. This is a crucial aspect of the integration, as OSL provides a self-service capability for tenants (e.g., telecom operators) to request Sylva’s Kubernetes-based workload clusters easily.

3. **Awareness of Operators and Management of Workload Cluster Resources**: After the workload cluster is created and managed by Sylva, OSL becomes aware of the workload cluster operators and the resources within the workload clusters. In this process, OSL is managing the workload cluster resources as if they were its own. OSL’s CRIDGE, is utilized to ensure that OSL is fully integrated and aware of the Sylva-managed resources.

4. **Deploy Resources in Workload Cluster**: Once the workload clusters are set up and managed, Cloud-Native Functions (CNF) are deployed in the clusters. These CNFs represent the telco workloads and applications that the operator needs to manage. The deployment of CNFs takes place in the workload clusters, utilizing Sylva’s capabilities to handle these resources efficiently.

![OSL - Sylva integration](./images/osl_sylva_integration.png)

## Probe further

More details of each aspects of the approach can be found in the following three-part news blogposts:

1. [Details in Identity and Access Management](https://osl.etsi.org/news/20241015_osl_sylva_part1/)

2. [Sylva Workload Cluster as a Service](https://osl.etsi.org/news/20241022_osl_sylva_part2/)

3. [Awareness of resources in a Sylva Workload Cluster](https://osl.etsi.org/news/20241104_osl_sylva_part3/)

Additional complementary material:

* The Addon’s source code is in the respective [OSL GitLab repository](https://labs.etsi.org/rep/osl/code/addons/org.etsi.osl.controllers.sylva). 

* You may also check the related [video demonstration](https://www.youtube.com/watch?v=dgrLVD9Sejw).

 No newline at end of file

# Catalogs and Templates

The OpenSlice Service Catalogue (accessible through the API or Services portal) contains the representation of Service Specifications, either created from the provider defining service attributes, or by supporting the GSMA Generic Slice Templates (GST) as well as the VINNI Service Blueprint. The following scenarios are supported by the OpenSlice Service Catalogue.

The OpenSlice Service Catalogue (accessible through the API or Services portal) contains the representation of Service Specifications, either created from the provider defining service attributes, or by supporting the GSMA Generic Slice Template (GST). The following scenarios are supported by the OpenSlice Service Catalogue.

## Create/Design a Service Specification

## Probe further

[Design Kubernetes-based Service Specifications](./kubernetes/exposing_kubernetes_resources.md/)

Design and expose services based on:

[Design NFV/OSM-based Service Specifications](./nfv/design_nfv_services.md)

* [Containerized resources via the Kubernetes Operator pattern](./kubernetes/exposing_kubernetes_resources.md)

* [NFV artifacts](./nfv/design_nfv_services.md)

* [Monitoring sources](./monitoring/design_monitoring_services.md)

* [Generic, developer-owned controllers](./generic/design_generic_services.md)

# Design Generic Services

**Intended Audience: OpenSlice Service Designers**

This section introduces a way to integrate generic and developer-owned services/controllers within the OpenSlice (OSL) lifecycle. 

## Introduction

Since Release 2024Q2, OSL introduces extensive support for Kubernetes operators exposed as services within OSL catalogs. However, inspired by the operator pattern, developers can now write their own resource controllers and attach them to the OSL service bus. OSL's Service orchestrator (OSOM) has the capability of contacting external controllers, given a specific resource category that this controller can manage.

The intended goal is to write a controller that can handle resources of a specific type, e.g., resource Specifications for managing resources of a specific category. Therefore, a new resource controller can be registered into OSL, in the form of a Resource Specification with a designated name, category and version, and the implementation of the controller shall listen for messages in queues as specified by the name, category and version of the registered Resource Specification. Specifically, it shall listen for CREATE/UPDATE/DELETE actions, with the following scheme:

- CREATE / category_name / version

- UPDATE / category_name / version

- DELETE / category_name / version

## Workflow

In a nutshell, the Resource Definition/Specification is registered at startup. During Service Orders of related-to-the-specification services, the controller is invoked (via message queue) and a new service and its underlying resource are created, with messages passing between the service and resource layers. The resource controller processes any updates or status changes. OSOM checks the final status of the deployed resource to confirm it is ready or identify any potential errors. The following diagram describes what the resource controller needs to perform, showcasing how the “Resource Controller” component interacts with various services (TMF API, Message Queue MQa, and OSOM) to register the needed resource types, create new resources (Resource Facing Services - RFSs and underlying resources), process updates, and check the resource’s status.

1.	**Controller Registration (top swimlane)** – This happens when the controller bootstraps

    * **Register a Resource Specification**: On startup, the Resource Controller posts a ResourceSpec (containing a name, category, and version) to register it in the OSL Resource Specification Catalog.

    * **QueueRegister**: The controller is registered in these three queues and listens on messages with ResourceCreate or ResourceUpdate payloads. -->

2.	**Create RFS (middle swimlane)** – This happens when there is a Service Order

    * **ServiceOrderCreate**: When a new RFS needs to be created, a “ServiceOrderCreate” operation via the TMFAPI arrives to OSOM.

    * **ServiceCreateMSG → ResourceCreateMSG**: Internally, a “ServiceCreateMSG” as well as a “ResourceCreateMSG” are sent to the TMFAPI component to create the related entities in the inventory.

    * **Resource Deployment**: OSOM sends a message to the queue under the specific queue name to CREATE the resource.

    * **CreateGenericResourceMSG**: A generic creation message is sent (e.g., CREATE/```{category_name}```/```{version}```), containing metadata such as ServiceID, ResourceID, and OrderID in the message headers.

        1. *org.etsi.osl.serviceId*: The related service ID that refers to the created resource. 

        2. *org.etsi.osl.resourceId*: The related resource ID that is the custom controller is expected to update.

        3. *org.etsi.osl.serviceOrderId*: The related service order id of the deployment request.

    * **WaitForResourceStatus**: OSOM waits for a status response indicating success or failure in creating the resource.

3.	**Resource Controller Process (lower-middle swimlane)**

    * **ProcessRequest**: After the resource is created, the Resource Controller processes any additional instructions or updates related to the resource.

    * **ResourceUpdate**: The resource is updated accordingly (e.g., changing configurations, state, etc.). The controller needs to update the resource into a valid state, e.g. AVAILABLE, RESERVED, or ALARM. For instance, if it is update in AVAILABLE state, OSOM later will assume that everything is OK, the service is ACTIVE, and the Service Order is COMPLETED, respectively.

4.	**OSOM Check Deployment (bottom swimlane)**

    * **GETResource → Check GETResource**: OSOM retrieves the resource information to verify its deployment and status.

    * **Check Resource Status**: OSOM checks whether the resource has transitioned into a valid operational state (e.g., AVAILABLE, RESERVED, or ALARM).

![Generic Controller Sequence Diagram](./images/generic_controller_seq_diagram.png)

## Probe further

A working example of such a generic controller can be found [here](https://labs.etsi.org/rep/osl/code/addons/org.etsi.osl.examples.gcontroller), written in Java, but in general you can implement one in any language.

 No newline at end of file