Demonstrating Synergies Between ETSI SDG OpenSlice (OSL) and LF Sylva: PART 1

The synergy between OpenSlice (OSL) and Sylva offers a powerful combination that addresses the increasing complexity of managing telco and edge cloud infrastructures. This blog explores how these two platforms—OpenSlice, an ETSI SDG-backed solution, and Sylva, a Linux Foundation project—can be integrated to optimize service orchestration and resource management for telecom operators.

OpenSlice (OSL) is an open-source software solution developed to streamline the provisioning and management of network services and resources. Supported by the ETSI SDG initiative, OSL provides an API-driven orchestration layer that allows service providers to manage resources efficiently. Its ability to automate service deployment and lifecycle management through TMF APIs offers significant operational benefits for network operators, reducing complexity while improving scalability. You can read more about OSL here: https://osl.etsi.org/

Sylva, a project under the Linux Foundation, is designed to meet the unique demands of the telecom and edge cloud sectors. As telco networks increasingly transition toward edge computing environments, Sylva provides a tailored cloud software framework for these specialized needs. It not only addresses 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/

The synergy between OSL and Sylva 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.

Key Benefits of the Integration

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.

Synergies of the Integration

In the series of this blog we will explore various synergies, as high level illustrated in following figure which depicts the integration and synergies between OpenSlice (OSL) and Sylva, specifically focusing on how workload clusters are requested, managed, and utilized in a telecom environment.

In the end we would like to offer Sylva workload clusters as a service, but also with a single Service order to manage them and install automatically CNFs, for example a 5G core. So, the end-users will just order a 5G core and OSL with Sylva will deliver a new cluster with the 5G core automatically installed and provisioned.

The goal of this demonstration is not to deliver a complete product-grade solution but rather to showcase different aspects of OSL as well as some recently developed extension mechanisms. OSL users can further build more fine-grained solution to offer their internal services (e.g. to connect the 5G core with their Radio Nodes, use multiple networks, expose services, etc)

There are four aspects that we will investigate and demonstrate.

1. Identity and Access Management (IAM)

Keycloak is used for Identity and Access Management (IAM) in this setup. Both the 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 easily request Sylva’s Kubernetes-based workload clusters.

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 CRIDGE, is utilized to ensure 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.

Part 1: Identity and Access Management

In this Part 1 of our blog series, we will review the Identity and Access Management aspect. Both OSL and Sylva use Keycloak (a well-known open source identity and access management solution). In this article we will explore how OSL can use Sylva’s Keycloak installation. This will allow seamless experience for Sylva and OSL users, since that with one account they can visit and use multiple services, with specific roles. We assume that the Sylva keycloak installation can be accessed via https://keycloak.sylva

We will need to create a sylva-osl-admin user in the sylva realm, able to access both Sylva and OSL services. To achieve this, we need to perform the following steps:

• Create client osapiWebClientId in Keycloak (define valid redirect URIs, web orings, etc)
• Add admin, openapi, read,write client scopes
• Create in sylva realm roles ADMIN and USER
• Create user sylva-osl-admin and assign roles to user

The following images depict the above steps:

A next issue is that API needs to trust https://keycloak.sylva (especially in our case since the certificate is private). Assuming that we run OSL in docker compose or in a kubernetes cluster in general we need to

• Create a folder cert in docker compose folder
• Create a Custom Truststore

echo | openssl s_client -showcerts -servername keycloak.sylva -connect keycloak.sylva:443 | openssl x509 -inform pem -outform pem -out server-cert.pem
keytool -importcert -alias keycloak.sylva -file server-cert.pem -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit

• Modify docker compose

image: labs.etsi.org:5050/osl/code/org.etsi.osl.tmf.api:latest
  command: ["java", "-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts/my-truststore.jks", "-Djavax.net.ssl.trustStorePassword=changeit", "-jar", "/opt/openslice/lib/org.etsi.osl.tmf.api-1.0.0-exec.jar"]  # Override default command
……
 volumes:
    - ./repo:/root
    - ./cert:/etc/ssl/certs/java/cacerts

• Docker compose up and login to OpenSlice with user sylva-osl-admin

From this point on we can use the same user (sylva-osl-admin) across OSL and Sylva. See the following figure after login to OpenSlice UI

In our next part of this series, we will explore the request for Sylva Workload Clusters

#OpenSource #OpenSlice #ETSI #SYLVA #LINUXFOUNDATION