Update all docs for Release EIGHTEEN

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 SIXTEEN or Release FOURTEEN (2 years support) and Standard releases (6 months support).

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

This release, **Release SEVENTEEN**, which will be a Standard release with support for 6 months, means the consolidation of the new architecture and scope introduced in the previous release, positioning OSM as a generalized cloud-native orchestrator for infrastructure, platforms and services. The full cloud-native management of Kubernetes clusters introduced in Release SIXTEEN for public clouds has been extended to private clouds based on Openstack, following the same intent-based GitOps model where every operation related to the clusters or the applications running on them is done through Git repositories.

This release, **Release EIGHTEEN**, which will be an LTS release with support for 2 years, builds upon the architectural evolution of previous releases, further consolidating OSM as a cloud-native orchestrator for infrastructure, platforms, and services. This release introduces significant advancements in declarative operations, cluster management, and modular installation, reinforcing OSM’s position as a leading open-source orchestration solution.

OSM Release SEVENTEEN includes significant improvements in the following key areas:

OSM Release EIGHTEEN includes the following highlights:

- __Management of Kubernetes clusters__. This release includes the full life-cycle management of Kubernetes clusters on Openstack-based private clouds using Cluster API. The capabilities of declarative management of Kubernetes clusters and their workloads introduced in Release SIXTEEN have been leveraged and extended to support clusters based on Cluster API in private clouds based on OpenStack, which paves the way of supporting additional types of private infrastructure in next releases. 

- __OSM NF catalogue and testing__. Release SEVENTEEN sets the foundation of an OSM catalogue of NF and NS packages, that will become the foundation to promote OSM use cases during 2025. Existing NF and NS packages in OSM repos have been published in a public NF catalogue. In addition, new tools have been developed to simplify the creation of new OSM blueprints for Kubernetes applications (OSM Kubernetes Applications, OKA), suitable for the new intent-based framework of OSM. In addition, the automatic generation of E2E Robot tests from a set of NF and NS packages is now possible, which enables the incorporation of relevant NF packages and use cases to OSM’s recurring validation tests at ETSI’s environment.

- __Enhanced capabilities for Network Services__. This release allows to specify, as part of the instantiation parameters, the security groups or VIM flavours to be used by the different Virtualized Deployment Units (VDU) that are part of a VNF.

- __Improvements in CNF operation__. Release SEVENTEEN supports the relocation of the different Kubernetes Deployment Units (KDU) of a CNF between Kubernetes nodes in a cluster. This would allow the migration of KDU instances between locations in Kubernetes clusters such as the ones used in Edge scenarios, with a centralized control plane and distributed workers.

- __OSM installation__. This release introduces performance optimizations in Kafka, MongoDB and Airflow components, that are part of OSM installation, reducing the footprint of the OSM community installation.

- __OSM client improvements__. Release SEVENTEEN incorporates support of Jsonpath output format for the new commands related to intent-based operations (clusters, profiles, OKA, KSU). This format allows to filter the fields in the objects, following the common practices in other CLI tools such as kubectl.

- __Advanced Application Modelling__. It introduces Applications as first-class entities using declarative, intent-driven models. Enhancements include:

  - Structured OKA blueprints for components, traits, and transformations.

  - Unified Argo Workflow for all App operations.

  - Support for multiple, optional KSUs per App.

  - New SDK for high-level, type-safe transformation scripting.

- __Enhanced Cluster Management__. It adds OpenShift cluster support and multi-node group management for AWS clusters, improving flexibility and scalability.

- __New VIM Connectors__. It includes a VMware vCenter plugin with VM console access, expanding IaaS support.

- __Modular Installation__. OSM installation is now modular and customizable. Airflow and MongoDB are integrated into a unified Helm chart, creating a single all-in-one OSM helm chart that includes all components. 

- __Service Assurance Framework Updates__. Legacy POL and PLA modules have been removed, and MON module has been simplified to retain only the dashboarder, aligning with long-term Service Assurance (SA) strategy.

![Release SEVENTEEN - Feature summary](assets/rel17-features.png)

![Release EIGHTEEN - Feature summary](assets/rel18-features.png)

For a comprehensive overview of OSM functionalities, you can also refer to the [OSM White Papers and Release Notes of previous releases](https://osm.etsi.org/wikipub/index.php/Release_notes_and_whitepapers).

## OSM in practice

**OSM in Practice**:

**OSM Release SEVENTEEN Webinar**:

<iframe src="https://www.youtube.com/embed/kCFxPV67Adw?" width="640" height="360" frameborder="0" allowfullscreen="true" style="box-sizing: border-box;"></iframe>

<iframe src="https://www.youtube.com/embed/hMDCkqso-pU?" width="640" height="360" frameborder="0" allowfullscreen="true" style="box-sizing: border-box;"></iframe>

**Cluster management in Openshift-based infrastructures**:

<iframe src="https://www.youtube.com/embed/g2l_Og2fvA0?" width="640" height="360" frameborder="0" allowfullscreen="true" style="box-sizing: border-box;"></iframe>

## Assumptions about interaction with VIMs and VNFs

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

```bash

wget https://osm-download.etsi.org/ftp/osm-17.0-seventeen/install_osm.sh

wget https://osm-download.etsi.org/ftp/osm-18.0-eighteen/install_osm.sh

chmod +x install_osm.sh

./install_osm.sh

```

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

```bash

wget https://osm-download.etsi.org/ftp/osm-17.0-seventeen/install_osm.sh

wget https://osm-download.etsi.org/ftp/osm-18.0-eighteen/install_osm.sh

chmod +x install_osm.sh

./install_osm.sh 2>&1 | tee osm_install_log.txt

```

Once you have one host available with the characteristics above, you just need to trigger the OSM installation by:

```bash

wget https://osm-download.etsi.org/ftp/osm-17.0-seventeen/install_osm.sh

wget https://osm-download.etsi.org/ftp/osm-18.0-eighteen/install_osm.sh

chmod +x install_osm.sh

./install_osm.sh

```

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

```bash

wget https://osm-download.etsi.org/ftp/osm-17.0-seventeen/install_osm.sh

wget https://osm-download.etsi.org/ftp/osm-18.0-eighteen/install_osm.sh

chmod +x install_osm.sh

./install_osm.sh 2>&1 | tee osm_install_log.txt

```

Although the OSM Client is always available in the host machine after installation, it is sometimes convenient installing an OSM Client in another location, different from the OSM host, so that the access to the OSM services does not require OS-level/SSH credentials. Thus, in those cases where you have an OSM already installed in a remote server, you can still operate it from your local computer using the OSM Client.

### How to install standalone OSM Client using debian packages

### How to install standalone OSM Client

In order to install the OSM Client in your local Linux machine, you should follow this procedure:

```bash

# Clean the previous repos that might exist

sudo sed -i "/osm-download.etsi.org/d" /etc/apt/sources.list

wget -qO - https://osm-download.etsi.org/repository/osm/debian/ReleaseSEVENTEEN/OSM%20ETSI%20Release%20Key.gpg | sudo apt-key add -

sudo add-apt-repository -y "deb [arch=amd64] https://osm-download.etsi.org/repository/osm/debian/ReleaseSEVENTEEN stable devops IM osmclient"

sudo apt-get update

sudo apt-get install -y python3-pip

sudo apt-get install -y python3-osm-im python3-osmclient

python3 -m pip install -r /usr/lib/python3/dist-packages/osm_im/requirements.txt

python3 -m pip install -r /usr/lib/python3/dist-packages/osmclient/requirements.txt

OSM_CLIENT_VERSION="v18.0"

OSM_IM_VERSION="v18.0"

sudo DEBIAN_FRONTEND=noninteractive apt-get install -y python3 python3-setuptools python3-dev python3-pip

sudo DEBIAN_FRONTEND=noninteractive apt-get install -y libmagic1

sudo DEBIAN_FRONTEND=noninteractive apt-get install -y make

sudo -H python3 -m pip install -U pip

# Install OSM IM and its dependencies via pip

python3 -m pip install -r "https://osm.etsi.org/gitweb/?p=osm/IM.git;a=blob_plain;f=requirements.txt;hb=${OSM_IM_VERSION}"

# Path needs to include $HOME/.local/bin in order to use pyang

[ "$(which pyang)" = "$HOME/.local/bin/pyang" ] || export PATH=$HOME/.local/bin:${PATH}

python3 -m pip install "git+https://osm.etsi.org/gerrit/osm/IM.git@${OSM_IM_VERSION}#egg=osm-im" --upgrade

python3 -m pip install -r "https://osm.etsi.org/gitweb/?p=osm/osmclient.git;a=blob_plain;f=requirements.txt;hb=${OSM_CLIENT_VERSION}"

python3 -m pip install git+https://osm.etsi.org/gerrit/osm/osmclient.git@${OSM_CLIENT_VERSION}#egg=osmclient

```

### Usage

When OSM is installed, behind the scenes the following steps are done:

- Installation of local LXD server (required for LXD-based proxy charms)

- Installation of Docker CE

- Installation and initialization of a local Kubernetes cluster, including a CNI (Flannel), container storage (OpenEBS) and a Load Balancer (MetalLB)

- Installation of Juju client

- Bootstraping of juju controller to allow the deployment of Execution Environments in local LXD server and local Kubernetes cluster

- Deployment of OSM

  - Deployment of Mongo DB charm with juju

  - Deployment of OSM services with the OSM Helm Chart, which includes the following components:

- Installation of client tools

- Installation and initialization of a local Kubernetes cluster, including a CNI , container storage (OpenEBS) and a Load Balancer (MetalLB)

- Deployment auxiliary services (Git, S3)

- Deploy of management cluster services (FluxCD, ArgoWorkflows, Crossplane, CAPI)

- Deployment of OSM with the OSM Helm Chart, which includes the following components:

  - NBI

  - LCM

  - RO

  - NG-UI

  - MON

  - Webhook translator

    - Other (Mysql, Keystone, Zookeeper, Kafka, Prometheus, Grafana)

  - Deployment of NG-SA (new Service Assurance), which includes Airflow, Prometheus Alert Manager and Prometheus Pushgateway Helm Charts

- Installation of OSM client

  - NG-SA (new Service Assurance), which includes Airflow, Prometheus Alert Manager and Prometheus Pushgateway Helm Charts

  - Other (Mysql, Keystone, Kafka, Prometheus, Grafana)

Once OSM is installed, the following helm releases can be seen in namespace `osm`:

```bash

$ helm -n osm ls

NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION

airflow         osm             1               2023-06-07 15:08:48.613039036 +0000 UTC deployed        airflow-1.9.0                   2.5.3

alertmanager    osm             1               2023-06-07 15:10:23.448079581 +0000 UTC deployed        alertmanager-0.22.0             v0.24.0

osm             osm             1               2023-06-07 15:08:43.421836769 +0000 UTC deployed        osm-0.0.1                       14

pushgateway     osm             1               2023-06-07 15:10:19.507304535 +0000 UTC deployed        prometheus-pushgateway-1.18.2   1.4.2

osm             osm             1               2025-09-07 15:08:43.421836769 +0000 UTC deployed        osm-18.0.0                      18.0.0

```

The helm release `osm` corresponds to the OSM Helm chart.

## How to install OSM using OSM helm chart

Assuming that you have a Kubernetes cluster, and you have bootstrapped a Juju controller there, it is possible to deploy OSM on top of that cluster.

Assuming that you have a Kubernetes cluster, it is possible to deploy OSM on top of that cluster.

### Deploy MongoDB using helm chart

The following instructions assume that helm is installed and default storage class is available in kubernetes cluster.

### Deploy OSM helm chart directly from Gitlab OCI repo

```bash

git clone "https://osm.etsi.org/gerrit/osm/devops"

cd devops

# Optionally check out a specific version

# DESIRED_OSM_VERSION="15.0.0"

# git checkout $DESIRED_OSM_VERSION

MONGODB_HELM_VERSION="13.9.4"

helm repo add bitnami https://charts.bitnami.com/bitnami

helm repo update

# Check that there are no errors and deploy

helm template mongodb-k8s bitnami/mongodb -n osm  -f installers/helm/values/mongodb-values.yaml --version ${MONGODB_HELM_VERSION}

# install mongodb

helm install mongodb-k8s bitnami/mongodb -n osm --create-namespace -f installers/helm/values/mongodb-values.yaml --version ${MONGODB_HELM_VERSION}

```

### Deploy Cert-manager

```bash

CERTMANAGER_VERSION="v1.9.1"

helm repo add jetstack https://charts.jetstack.io

helm repo update

helm install cert-manager --create-namespace --namespace cert-manager jetstack/cert-manager \

    --version ${CERTMANAGER_VERSION} --set installCRDs=true --set prometheus.enabled=false \

    --set clusterResourceNamespace=osm \

    --set extraArgs="{--enable-certificate-owner-ref=true}"

```

### Deploy OSM helm chart

#### Deploy OSM helm chart directly from Gitlab OCI repo

```bash

helm install -n osm osm oci://osm.etsi.org:5050/osm/devops/osm --version 16.0.0

helm install -n osm osm oci://osm.etsi.org:5050/osm/devops/osm --version 18.0.0

# Optionally pull, then install

# helm pull osm oci://osm.etsi.org:5050/osm/devops/osm --version 16.0.0

# helm install -n osm --repo osm osm-16.0.0.tgz

# helm pull osm oci://osm.etsi.org:5050/osm/devops/osm --version 18.0.0

# helm install -n osm --repo osm osm-18.0.0.tgz

```

#### Deploy OSM helm chart from devops repo

### Deploy OSM helm chart from devops repo

```bash

# Make sure you are in devops directory

cd devops

# Optionally check out a specific version

# DESIRED_OSM_VERSION="15.0.0"

# DESIRED_OSM_VERSION="18.0.0"

# git checkout $DESIRED_OSM_VERSION

# Check default values

# Specify the repository base and the version that you want for the docker images

OSM_HELM_OPTS=""

OSM_HELM_OPTS="${OSM_HELM_OPTS} --set global.image.repositoryBase=opensourcemano"

OSM_HELM_OPTS="${OSM_HELM_OPTS} --set global.image.tag=\"16\""

OSM_HELM_OPTS="${OSM_HELM_OPTS} --set global.image.tag=\"18\""

# Build the helm chart dependencies 

helm dependency build installers/helm/osm

helm -n osm status osm

```

#### Specific instructions if Juju is used

Get Juju host, secret, public key and CA certificate:

```bash

function parse_juju_password {

    [ -z "${DEBUG_INSTALL}" ] || DEBUG beginning of function

    password_file="${HOME}/.local/share/juju/accounts.yaml"

    local controller_name=$1

    local s='[[:space:]]*' w='[a-zA-Z0-9_-]*' fs=$(echo @|tr @ '\034')

    sed -ne "s|^\($s\):|\1|" \

         -e "s|^\($s\)\($w\)$s:$s[\"']\(.*\)[\"']$s\$|\1$fs\2$fs\3|p" \

         -e "s|^\($s\)\($w\)$s:$s\(.*\)$s\$|\1$fs\2$fs\3|p" $password_file |

    awk -F$fs -v controller=$controller_name '{

        indent = length($1)/2;

        vname[indent] = $2;

        for (i in vname) {if (i > indent) {delete vname[i]}}

        if (length($3) > 0) {

            vn=""; for (i=0; i<indent; i++) {vn=(vn)(vname[i])("_")}

            if (match(vn,controller) && match($2,"password")) {

                printf("%s",$3);

            }

        }

    }'

    [ -z "${DEBUG_INSTALL}" ] || DEBUG end of function

}

OSM_VCA_HOST=$(juju show-controller osm |grep api-endpoints|awk -F\' '{print $2}'|awk -F\: '{print $1}')

OSM_VCA_SECRET=$(parse_juju_password osm)

OSM_VCA_CACERT=$(juju controllers --format json | jq -r --arg controller osm '.controllers[$controller]["ca-cert"]' | base64 | tr -d \\n)

OSM_VCA_PUBKEY=$(cat $HOME/.local/share/juju/ssh/juju_id_rsa.pub)

# Generate helm values to be passed with -f osm-values.yaml

sudo bash -c "cat << EOF > osm-values.yaml

vca:

  pubkey: \"${OSM_VCA_PUBKEY}\"

EOF"

# Customize your own helm options (--set ...)

OSM_HELM_OPTS="${OSM_HELM_OPTS} --set vca.host=${OSM_VCA_HOST}"

OSM_HELM_OPTS="${OSM_HELM_OPTS} --set vca.secret=${OSM_VCA_SECRET}"

OSM_HELM_OPTS="${OSM_HELM_OPTS} --set vca.cacert=${OSM_VCA_CACERT}"

```

### Deploy NG-SA

```bash

AIRFLOW_HELM_VERSION=1.9.0

PROMPUSHGW_HELM_VERSION=1.18.2

ALERTMANAGER_HELM_VERSION=0.22.0

# Update installers/helm/values/airflow-values.yaml if needed

#   update defaultAirflowTag if needed (e.g. "14")

#   uppate defaultAirflowRepository (e.g. "opensourcemano/airflow")

# Deploy Apache Airflow

helm repo add apache-airflow https://airflow.apache.org

helm repo update

# Check that there are no errors and deploy

helm -n osm template airflow apache-airflow/airflow -f installers/helm/values/airflow-values.yaml --version ${AIRFLOW_HELM_VERSION}

helm -n osm install airflow apache-airflow/airflow -f installers/helm/values/airflow-values.yaml --version ${AIRFLOW_HELM_VERSION}

# Deploy Prometheus Pushgateway and Alert Manager

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

helm repo update

# Check that there are no errors and deploy

helm -n osm template pushgateway prometheus-community/prometheus-pushgateway --version ${PROMPUSHGW_HELM_VERSION}

helm -n osm install pushgateway prometheus-community/prometheus-pushgateway --version ${PROMPUSHGW_HELM_VERSION}

helm -n osm template alertmanager prometheus-community/alertmanager -f installers/helm/values/alertmanager-values.yaml --version ${ALERTMANAGER_HELM_VERSION}

helm -n osm install alertmanager prometheus-community/alertmanager -f installers/helm/values/alertmanager-values.yaml --version ${ALERTMANAGER_HELM_VERSION}

```

### Check the status of helm releases and pods

Run the following commands to check the status of helm releases and the pods. All pods should have started properly.

The installation can be performed with the following command:

```bash

wget https://osm-download.etsi.org/ftp/osm-17.0-seventeen/install_osm.sh

wget https://osm-download.etsi.org/ftp/osm-18.0-eighteen/install_osm.sh

chmod +x install_osm.sh

./install_osm.sh -O <openrc file/cloud name> -N <OpenStack public network name/ID> [--volume] [OSM installer options]

```

### Specify IP profile information and IP for a NS VLD <a name="specify-ip-profile-information-and-ip-for-a-ns-vld">

In a generic way, the mapping can be specified in the following way, where `datanet` is the name of the network in the NS descriptor, ip-profile is where you have to fill the associated parameters from the data model ( [NS data model](https://osm-download.etsi.org/repository/osm/debian/ReleaseSEVENTEEN/docs/osm-im/osm_im_trees/etsi-nfv-nsd.html) ), and vnfd-connection-point-ref is the reference to the connection point:

In a generic way, the mapping can be specified in the following way, where `datanet` is the name of the network in the NS descriptor, ip-profile is where you have to fill the associated parameters from the data model ( [NS data model](https://osm-download.etsi.org/repository/osm/debian/ReleaseEIGHTEEN/docs/osm-im/osm_im_trees/etsi-nfv-nsd.html) ), and vnfd-connection-point-ref is the reference to the connection point:

```yaml

--config '{vld: [ {name: datanet, ip-profile: {...}, vnfd-connection-point-ref: {...} } ] }'

### Specify IP profile information for an internal VLD of a VNF

In this scenario, the mapping can be specified in the following way, where `vnf1` is the member vnf index of the constituent vnf in the NS descriptor, `internal` is the name of internal-vld in the VNF descriptor and ip-profile is where you have to fill the associated parameters from the data model ([VNF data model](https://osm-download.etsi.org/repository/osm/debian/ReleaseSEVENTEEN/docs/osm-im/osm_im_trees/etsi-nfv-vnfd.html)):

In this scenario, the mapping can be specified in the following way, where `vnf1` is the member vnf index of the constituent vnf in the NS descriptor, `internal` is the name of internal-vld in the VNF descriptor and ip-profile is where you have to fill the associated parameters from the data model ([VNF data model](https://osm-download.etsi.org/repository/osm/debian/ReleaseEIGHTEEN/docs/osm-im/osm_im_trees/etsi-nfv-vnfd.html)):

```yaml

--config '{vnf: [ {member-vnf-index: vnf1, internal-vld: [ {name: internal, ip-profile: {...} ] } ] }'

#### Specify IP address for an interface

In this scenario, the mapping can be specified in the following way, where `vnf1` is the member vnf index of the constituent vnf in the NS descriptor, 'internal' is the name of internal-vld in the VNF descriptor, ip-profile is where you have to fill the associated parameters from the data model ([VNF data model](https://osm-download.etsi.org/repository/osm/debian/ReleaseSEVENTEEN/docs/osm-im/osm_im_trees/etsi-nfv-vnfd.html)), `id1` is the internal-connection-point id and `a.b.c.d` is the IP that you have to specify for this scenario:

In this scenario, the mapping can be specified in the following way, where `vnf1` is the member vnf index of the constituent vnf in the NS descriptor, 'internal' is the name of internal-vld in the VNF descriptor, ip-profile is where you have to fill the associated parameters from the data model ([VNF data model](https://osm-download.etsi.org/repository/osm/debian/ReleaseEIGHTEEN/docs/osm-im/osm_im_trees/etsi-nfv-vnfd.html)), `id1` is the internal-connection-point id and `a.b.c.d` is the IP that you have to specify for this scenario:

```yaml

--config '{vnf: [ {member-vnf-index: vnf1, internal-vld: [ {name: internal, ip-profile: {...}, internal-connection-point: [{id-ref: id1, ip-address: "a.b.c.d"}] ] } ] }'

```bash

osm ns-create --ns_name hf-basic --nsd_name hackfest_basic-ns

With the previous hackfest example, according to [VNF data model](https://osm-download.etsi.org/repository/osm/debian/ReleaseSEVENTEEN/docs/osm-im/osm_im_trees/etsi-nfv-vnfd.html) you will add in VNF Descriptor:

With the previous hackfest example, according to [VNF data model](https://osm-download.etsi.org/repository/osm/debian/ReleaseEIGHTEEN/docs/osm-im/osm_im_trees/etsi-nfv-vnfd.html) you will add in VNF Descriptor:

```yaml

     volumes:

### Creating a Network Slice Template (NST)

Based on the OSM information model for Network slice templates [here](http://osm-download.etsi.org/repository/osm/debian/ReleaseSEVENTEEN/docs/osm-im/osm_im_trees/nst.html) it is possible to start writing the YAML descriptor for the NST.

Based on the OSM information model for Network slice templates [here](http://osm-download.etsi.org/repository/osm/debian/ReleaseEIGHTEEN/docs/osm-im/osm_im_trees/nst.html) it is possible to start writing the YAML descriptor for the NST.

```yaml

nst:

A sample CEF log for User login would be as below:

```text

CEF:0|OSM|OSM|17.0.0|User Login|1|msg=User Logged In, Project\=admin Outcome\=Success suser=admin

CEF:0|OSM|OSM|18.0.0|User Login|1|msg=User Logged In, Project\=admin Outcome\=Success suser=admin

```

### Audit Logs Prefixes