OSM release SEVEN: Container network functions and more

February 2020

By Tytus Kurek, Product Manager, Canonical Ltd. 

 

The OSM community was proud to announce OSM release SEVEN last December. This release introduces a range of exciting features, such as the ability to deploy container network functions on Kubernetes with k8s charms, and several improvements which enhance Open Source MANO (OSM) across various areas.

 

Container network functions support

In the 5G era, TSPs have started investigating the possibility of migrating from traditional virtual network functions (VNFs) to container network functions (CNFs). The migration is driven by the requirement for microservices architecture, better performance results and density provided by containers, edge deployments possibilities, more complex network services (NS) and better orchestration capabilities provided by container management platforms, such as Kubernetes.


Starting from release SEVEN, OSM now supports the possibility of deploying CNFs on Kubernetes with Helm charts and Juju k8s charms. While the Helm charts method supports the initial deployment only, the Juju k8s charms method extends it with support for performing day-1 and day-2 configuration. It achieves that by providing a native framework for implementing Kubernetes operators which are software extensions to Kubernetes, designed to manage applications and their components.


In order to add an existing Kubernetes cluster to your OSM installation, execute the following command:

$ osm k8scluster-add \

    --creds <path to k8s config file> \

    --vim <VIM name> \

    --k8s-nets "{(k8s_net1: <VIM network name>)}" \

    --version <Kubernetes version> \

    --namespace <namespace name> \

    --description "<description>" \

    <name>


For example, to add MicroK8s cluster while using MicroStack as a virtual infrastructure manager (VIM), run:


$ microk8s.config > ~/kubeconfig

$ osm k8scluster-add \

    --creds ~/kubeconfig \

    --vim microstack \

    --k8s-nets "{(k8s_net1: test)}" \

    --version 1.17 \

    --namespace test \

  --description "MicroK8s cluster" \

    microk8s


Then you can reference a Juju bundle inside of the VNF descriptor:


vnfd-catalog:

    vnfd:

    -   id: myvnf

        name: myvnf

        connection-point:

        -   name: mgmtnet

        mgmt-interface:

            cp: mgmt

        kdu:

        -   name: mykdu

            juju-bundle: <Juju bundle>

        k8s-cluster:

            nets:

            -   id: mgmtnet

                external-connection-point-ref: mgmt


For example:


vnfd-catalog:

    vnfd:

    -   id: myvnf

        name: myvnf

        connection-point:

        -   name: mgmtnet

        mgmt-interface:

            cp: mgmt

        kdu:

        -   name: mykdu

            juju-bundle: cs:~aisrael/bundle/mediawiki-k8s-0

        k8s-cluster:

            nets:

            -   id: mgmtnet

                external-connection-point-ref: mgmt


Finally, create the NS:


$ osm ns-create \

    --ns_name <NS name> \

    --nsd_name <NS package name> \

    --vim_account <VIM> \

    --config '{vld: [ {name: <name>, vim-network-name: <VIM network name>} ] }'


For example:


$ osm ns-create \

    --ns_name CNF \

    --nsd_name ubuntu-cnf-ns \

    --vim_account microstack \

    --config '{vld: [ {name: mgmtnet, vim-network-name: test} ] }'

 

This will create a new Juju model under the LCM module and deploy the desired Juju bundle on Kubernetes. The osm ns-action command can be further used to perform day-1 / day-2 configuration.

OSM release SEVEN: other notable changes

Planning & optimisation
OSM now provides support for placement automation and optimisation. During the network service instantiation process, OSM has to decide which network functions go into which VIM. An optimal placement is a subject to cost of compute in VIMs, cost of links or NS interworking and constraints in NS interworking, such as latency or jitter. The placement feature makes this process fully automated and optimal.

100% Python 3

As Python 2.7 reached an End of Life status on the 1st of January 2020, the whole OSM code has been migrated to support Python 3. This includes both OSM services and OSM client migration.

Multi-VIM and multi-SDN support
Starting from release SEVEN, OSM includes an enhanced SDN Assist feature with high-level calls. Both SDN Assist and VIM connectors have been migrated to a Python plugin model. As of release SEVEN, an Azure VIM plugin is available, while Contrail SDN plugin is planned to be released with 7.1

Improved lifecycle and feedback
OSM now provides an improved VNF configuration interface. Real-time feedback is available upon request too.

Fault management and performance management
Starting from release SEVEN, fault and performance management is available for OSM modules. This also includes automated dashboards for enhanced usability.

https://www.python.org/doc/sunset-python-2/
OSM packages now pass through an improved validation during the VNF onboarding process.


For more information about OSM release SEVEN, watch the webinars:

Part 1: Overview of OSM Release SEVEN
Part 2: Running cloud-native Network Services with OSM Release SEVEN


Charmed OSM
OSM release SEVEN images are now also available in Charmed OSM distribution. Charmed OSM is a pure upstream OSM distribution, developed and maintained by Canonical, which uses Juju charms to simplify its deployments and operations.


To get started with Charmed OSM, read the following tutorial.