1. OSM Quickstart

Open Source MANO (OSM) is an ETSI-hosted open source community delivering a production-quality MANO stack for NFV, capable of consuming openly published information models, available to everyone, suitable for all VNFs, operationally significant and VIM-independent. OSM is aligned to NFV ISG information models while providing first-hand feedback based on its implementation experience.

OSM follows a regular cadence of two releases per year, alternating between Long Term Support (LTS) releases such as Release FOURTEEN or Release TWELVE (2 years support) and Standard releases (6 months support).

This release, Release FIFTEEN, which will be a Standard release with support for 6 months, includes significant improvements in many key areas:

NS instantiation and lifecycle management. Release FIFTEEN enables new use cases in private clouds based on Openstack such as the support of Service Function Chaining and the support of Availability Zones for Cinder-based storage when instantiating a Network Function. In addition, a new cancel operation has been added for Network Service lifecycle, which will allow cancelling a pending action over a Network Service.
Kubernetes support. This release will include the support of OCI registries for Helm-based Kubernetes Deployment Units (KDU), which will allow OSM to retrieve helm charts from both authenticated and non-authenticated OCI registries, which are becoming a de-facto standard repository for cloud native images and artifacts. Besides, the support of Helm v2 for Helm-based KDU and Execution Environments will be discontinued, following the upstream recommendation from Helm, which had already deprecated Helm v2 since 2020.
VNF Management interface. Release FIFTEEN continues adding functionality to the SOL003-based VNFM API offered by OSM, in addition to the main SOL005 NFVO API. Specifically, this release adds dual-stack IP support to enable operators to assign static both IPv4 and IPv6 addresses to VNFs launched through OSM VNFM API.
Closed-loop life cycle in public clouds. In the last two releases of OSM, a new Service Assurance framework based on Apache Airflow was introduced. Release FIFTEEN adds to this new SA framework the capability to gather resource consumption metrics from VMs deployed on Google Cloud, which, combined with the closed loop workflows incorporated in previous releases, enables instantly the auto-healing and auto-scaling capabilities for VNF running in Google Cloud.
OSM installation. This release leverages in the OSM helm chart introduced in Release FOURTEEN community installation and updates it to include as dependencies upstream helm charts for Kafka, Zookeeper, MongoDB and MySQL. By using the upstream helm charts, those components will be able to be maintained in a much more convenient and easier way, benefiting also from upstream built-in features such as replication and persistent storage. In addition, all container images that have reached or will reach shortly End-Of-Life support have been updated to guarantee a proper support in the coming years. Finally, upon discontinuation of Juju support in future LTS releases, Release FIFTEEN paves the way by making optional the use of Juju and its dependencies in the community installer. As a result, Juju-based EE and KDU will be available only if the Juju is installed with OSM.
E2E testing. In this release cycle, the pipeline of OSM has evolved to include periodic tests of OSM over Azure Public cloud. The implemented pipeline enables the periodic and consistent evaluation of OSM behaviour over public clouds, currently on Azure and in other clouds in the future, such as AWS or Google Cloud. Besides, the E2E testing framework based on Robot has been enhanced to include the use of well-known linters for Robot framework such as Robocop and Robotframework-lint, which will help in the maintenance of OSM E2E tests.

Release FIFTEEN - Feature summary

For a comprehensive overview of OSM functionalities, you can also refer to the OSM White Papers and Release Notes of previous releases.

OSM in Practice:

1.1. Assumptions about interaction with VIMs and VNFs

The following figure illustrates OSM interaction with VIMs and VNFs:

OSM talks to the VIM for the deployment of VNFs and VLs connecting them
OSM talks to the VNFs deployed in a VIM to run day-0, day-1 and day-2 configuration primitives.

OSM

In order for OSM to work, it is assumed that:

Each VIM has an API endpoint reachable from OSM
Each VIM has a so called management network which provides IP address to VNFs
That management network is reachable from OSM

1.2. Installing OSM

1.2.1. Default installation procedure

All you need to run OSM is a single server or VM with the following requirements:

RECOMMENDED: 4 CPUs, 16 GB RAM, 80GB disk and a single interface with Internet access
Base image: Ubuntu22.04
- Ubuntu22.04 cloud image (64-bit variant required)
- Ubuntu22.04 server image (64-bit variant required)

Once you have prepared the host with the previous requirements, all you need to do is:

wget https://osm-download.etsi.org/ftp/osm-15.0-fifteen/install_osm.sh
chmod +x install_osm.sh
./install_osm.sh

This will install a standalone Kubernetes on a single host, and OSM on top of it.

TIP: In order to facilitate potential trobleshooting later, it is recommended to save the full log of your installation process:

wget https://osm-download.etsi.org/ftp/osm-15.0-fifteen/install_osm.sh
chmod +x install_osm.sh
./install_osm.sh 2>&1 | tee osm_install_log.txt

You will be asked if you want to proceed with the installation and configuration of LXD, juju, docker CE and the initialization of a local docker swarm, as pre-requirements. Please answer “y”.

1.2.1.1. Installation including optional components

You can include optional components in your installation by adding the following flags:

Juju and LXD: --juju --lxd (install Juju controller, required for VNFs that use Execution Environments based on Juju charms)
Kubernetes Monitor:: --k8s_monitor (install an add-on to monitor the Kubernetes cluster and OSM running on top of it, through prometheus and grafana)
PLA: --pla (install the PLA module for placement support)
Old Service Assurance: --old-sa (install old Service Assurance framework with MON and POL; do not install Airflow and Pushgateway)”

Example:

./install_osm.sh --juju --lxd

For other special installation options, please refer to the specific chapter on installation options.

1.2.2. Checking your installation

After some time, you will get a fresh OSM installation with its latest, pre-built docker images which are built daily. You can access to the UI in the following URL (user:admin, password: admin): http://1.2.3.4, replacing 1.2.3.4 by the IP address of your host.

OSM home

OSM installation result

As a result of the installation, different K8s objects (deployments, statefulsets, etc.) created in the host. You can check the status by running the following commands:

kubectl get all -n osm

To check the logs of any container:

kubectl logs -n osm deployments/lcm           # for LCM
kubectl logs -n osm deployments/ng-ui         # for NG-UI
kubectl logs -n osm deployments/mon           # for MON
kubectl logs -n osm deployments/nbi           # for NBI
kubectl logs -n osm deployments/pol           # for POL
kubectl logs -n osm deployments/ro            # for RO
kubectl logs -n osm deployments/keystone      # for Keystone
kubectl logs -n osm deployments/grafana       # for Grafana
kubectl logs -n osm statefulset/kafka         # for Kafka
kubectl logs -n osm statefulset/mongodb-k8s   # for MongoDB
kubectl logs -n osm statefulset/mysql         # for Mysql
kubectl logs -n osm statefulset/prometheus    # for Prometheus
kubectl logs -n osm statefulset/zookeeper     # for Zookeeper

Finally, if you used the option --k8s_monitor to install an add-on to monitor the K8s cluster and OSM, you can check the status in this way.

kubectl get all -n monitoring

OSM client, a python-based CLI for OSM, will be available as well in the host machine. Via the OSM client, you can manage descriptors, NS and VIM complete lifecycle.

osm --help

1.3. Adding VIM accounts

Before proceeding, make sure that you have a site with a VIM configured to run with OSM. Different kinds of VIMs are currently supported by OSM:

OpenStack. Check the following link to learn how to configure OpenStack to be used by OSM: Openstack configuration
Microsoft Azure Check the following link to learn how to configure Microsoft Azure to be used by OSM: Configuring Microsoft Azure for OSM
Google Cloud Platform (GCP) Check the following link to learn how to configure Google Cloud Platform to be used by OSM: Configuring Google Cloud Platform for OSM
Amazon Web Services (AWS). Check the following link to learn how to configure AWS (EC2 and Virtual Private Cloud) to be used by OSM: Configuring AWS for OSM
VMware vCloud Director. Check the following link to learn how to configure VMware VCD to be used by OSM: Configuring VMware vCloud Director
OpenVIM. Check the following link to know how to install and use openvim for OSM: OpenVIM installation. OpenVIM must run in ‘normal’ mode (not test or fake) to have real virtual machines reachable from OSM.

OSM can manage external SDN controllers to perform the dataplane underlay network connectivity on behalf of the VIM. See EPA and SDN assist

1.3.1. Adding VIMs through OSM client

1.3.1.1. Openstack site

Execute the following command, using the appropriate parameters (e.g. site name: “openstack-site”, IP address: 10.10.10.11, VIM tenant: “admin”, user: “admin”, password: “userpwd”)

osm vim-create --name openstack-site --user admin --password userpwd \
    --auth_url http://10.10.10.11:5000/v2.0 --tenant admin --account_type openstack

For advanced options, please refer to the OpenStack Setup Guide.

1.3.1.2. VMware Integrated Openstack (VIO) site

Execute the following command, using the appropriate parameters (e.g. site name: “openstack-site-vio4”, IP address: 10.10.10.12, VIM tenant: admin, user: admin, password: passwd)

osm vim-create --name VIO --user admin --password passwd --auth_url https://10.10.10.12:5000/v3 --tenant admin \
    --account_type openstack --config '{use_floating_ip: True, insecure: true, vim_type: VIO, APIversion: v3.3,
    dataplane_physical_net: dvs-46, "use_internal_endpoint":true,"dataplane_net_vlan_range":["31-35","37-39"]}'

With respect to Openstack, the additional configuration for VIO is the following:

vim_type: Set to “VIO” to use VMware Integrated openstack as VIM
use_internal_endpoint: When true it allows use of private API endpoints
dataplane_physical_net: The configured network_vlan_ranges at neutron for the SRIOV (binding direct) and passthrough (binding direct-physical) networks, e.g. ‘physnet_sriov’ in the above configuration. In case of VMware Integrated Openstack (VIO) provide moref ID of distributed virtual switch, e.g ‘dvs-46’ in above configuration.
dataplane_net_vlan_range: In case of VMware Integrated Openstack (VIO) provide vlan ranges for the SRIOV (binding direct) networks in format [’start_ID - end_ID’]

For common options, you may refer to the general OpenStack Setup Guide.

1.3.1.3. Amazon Web Services (AWS) site

Execute the following command, using the appropriate parameters (e.g. site name: “aws-site”, VIM tenant: “admin”, user: “XXX”, password: “YYY”)

osm vim-create --name aws-site --user XXX --password YYY --auth_url https://aws.amazon.com --tenant admin \
    --account_type aws --config '{region_name: eu-central-1, flavor_info: {t2.nano: {cpus: 1, disk: 100, ram: 512},
    t2.micro: {cpus: 1, disk: 100, ram: 1024}, t2.small: {cpus: 1, disk: 100, ram: 2048},
    m1.small: {cpus: 1, disk: 160, ram: 1741}}}'

For advanced options, please refer to the Configuring AWS for OSM.

1.3.1.4. Microsoft Azure

Execute the following command, using the appropiate parameters (e.g azure_client_id: ‘XXX’, azure_secret: ‘YYY’, azure_tenant: ‘tenantid’, azure_subscription_id: ‘ZZZ’, regular expression of the flavors that will be used: flavors_pattern:’^Basic’)

osm vim-create --name azure --account_type azure --auth_url http://www.azure.com --tenant "tenantid"
    --user "XXX" --password "azurepwd" --description "AZURE site"
    --config "{region_name: westeurope, resource_group: 'osmRG', subscription_id: 'azuresubs',
     vnet_name: 'osm_vnet', flavors_pattern: 'flavors_regex'}"

For advanced options, please refer to the Microsoft Azure setup guide.

1.3.1.5. OpenVIM site

Execute the following command, using the appropriate parameters (e.g. site name: “openvim-site”, IP address: 10.10.10.10, VIM tenant: “osm”)

osm vim-create --name openvim-site --auth_url http://10.10.10.10:9080/openvim --account_type openvim \
   --description "Openvim site" --tenant osm --user dummy --password dummy

1.3.1.6. VMware vCloud Director site

Execute the following command, using the appropriate parameters (e.g. site name: “vmware-site”, IP address: 10.10.10.12, VIM tenant: “vmware-tenant”, user: “osm”, password: “osm4u”, admin user: “admin”, admin password: “adminpwd”, organization: “orgVDC”)

osm vim-create --name vmware-site --user osm --password osm4u --auth_url https://10.10.10.12 \
    --tenant vmware-tenant  --account_type vmware \
    --config '{admin_username: user, admin_password: passwd, orgname: organization, nsx_manager: "http://10.10.10.12",
    nsx_user: user, nsx_password: userpwd,"vcenter_port": port, "vcenter_user":user, "vcenter_password":password,
    "vcenter_ip": 10.10.10.14}'

For advanced options, please refer to the Configuring VMware vCloud Director.

1.3.2. Adding VIMs through GUI

Just access the VIM Accounts tab, click the New VIM button and fill the parameters accordingly.

AddingVIMUI

1.4. Deploying your first Network Service

Before going on, get the required NF and NS packages from Gitlab osm-packages repository.

1.4.1. Onboarding a VNF

The onboarding of a VNF in OSM involves preparing and adding the corresponding VNF package to the system. This process also assumes, as a pre-condition, that the corresponding VM images are available in the VIM(s) where it will be instantiated.

1.4.1.1. Uploading VM image(s) to the VIM(s)

In this example, only a vanilla Ubuntu20.04 image is needed. It can be obtained from the following link: https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img

It will be required to upload the image into the VIM. Instructions differ from one VIM to another (please check the reference of your type of VIM).

For instance, this is the OpenStack command for uploading images:

openstack image create --file="./focal-server-cloudimg-amd64.img" --container-format=bare --disk-format=qcow2 ubuntu20.04

1.4.1.2. Onboarding a VNF Package

From the UI:
- Go to ‘VNF Packages’ on the ‘Packages’ menu to the left
- Drag and drop the VNF package file hackfest_basic_vnf.tar.gz in the importing area.

Onboarding a VNF

From OSM client:

osm nfpkg-create hackfest_basic_vnf.tar.gz
osm nfpkg-list

1.4.2. Onboarding a NS Package

From the UI:
- Go to ‘NS Packages’ on the ‘Packages’ menu to the left
- Drag and drop the NS package file hackfest_basic_ns.tar.gz in the importing area.

Onboarding a NS

From OSM client:

osm nspkg-create hackfest_basic_ns.tar.gz
osm nspkg-list

1.4.3. Instantiating the NS

1.4.3.1. Instantiating a NS from the UI

Go to ‘NS Packages’ on the ‘Packages’ menu to the left
Next the NS descriptor to be instantiated, click on the ‘Instantiate NS’ button.

Instantiating a NS (assets/600px-Nsd_list_r9.png)

Fill in the form, adding at least a name, description and selecting the VIM:

Instantiating a NS (assets/600px-New_ns_r9.png)

Instantiation parameters can be specified using both CLI and UI. You can find a thorough explanation with examples in this page: OSM instantiation parameters.

1.4.3.2. Instantiating a NS from the OSM client

osm ns-create --ns_name <ns-instance-name> --nsd_name hackfest_basic-ns --vim_account <vim-target-name>
osm ns-list

1.5. What’s next?

If you want to learn more, you can refer to the rest of OSM documentation.