Tytus Kurek
on 31 January 2020

Charmed OSM release SEVEN: Container network functions

charmed OSM OSM Telco Telecommunications

Canonical is proud to announce the general availability of OSM release SEVEN images in Charmed OSM distribution. OSM release SEVEN 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.

To learn more about Charmed OSM, visit our page.

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. Users can further use the osm ns-action command 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.

VNF onboarding

OSM packages now pass through an improved validation during the VNF onboarding process.

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

Try Charmed OSM by following this tutorial.