Update all docs for Release FIFTEEN

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 FOURTEEN**, offers a new scalable architecture for service assurance based on Apache Airflow and Prometheus and includes closed loops for auto-scaling and the handling of alerts coming from the Network Functions. In addition, the new architecture enables scheduled monitoring and service-assurance workflows, as well as alarm-based on-demand workflows. This capability will be key to supporting new telco cloud use cases in future Releases.

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).

Release FOURTEEN brings significant improvements in security, usability, platform management, infrastructure modelling and lifecycle management of network functions:

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

- **Security enhancements**. Release FOURTEEN introduced secured helm-based Execution Environments (EE) based on authenticated gRPC communication channel between EE and NF, and the use of pod admission policies to restrict EE permissions running in OSM cluster. In addition, Pycrypto library has been PycryptoDome, a more modern and secure cryptography library.

- **Usability and platform management**. This release includes relevant enhancements in user management such as the generation of standard audit logs for every user operation from any entity interacting with OSM North Bound Interface. In addition, retry and password expiry policies have been added to user management.

- **Infra modelling and NF lifecycle**. OSM has proved to be successful in production environments in the deployment of NS. This release goes even further and incorporates new capabilities for NS deployment such as the capability to attach multiple volumes to different VM, the capability to re-use existing flavors, the simultaneous support of IPv4 and IPv6 in VM network interfaces, or the ability to provide instantiation parameter to Juju-based Kubernetes Deployment Units. In addition, the release has optimized the interactions with VIMs to make deployment faster and more reliable. Finally, the release includes a new connector for Transport-API WIMs, which will enable the use of TeraFlow SDN or any other WIM in the future to build optical transport connectivity between datacenters.

- **OSM installation experience**. This release has modified the community installer to install all OSM components with a Helm chart rather than plain Kubernetes manifests, which will allow much simpler upgrades of OSM services from now on. 

- **OSM client**. Finally, this release includes some improvements in the OSM client, such as the support of different output formats for some commands and the replacement of Pycurl library by the well-known Requests library for HTTP interaction. Both features were developed by participants of the recent [OSM Hackfest for developers held in Castelldefels in June 2023](https://osm.etsi.org/wikipub/index.php/OSM15_Hackfest).

- __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.

For the full list of new features, please refer to the [Release Notes](https://osm-download.etsi.org/ftp/osm-14.0-fourteen/OSM_Release_FOURTEEN_Release_Notes.pdf). 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).

![Release FIFTEEN - Feature summary](assets/rel15-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).

<!--

For the full list of new features, please refer to the [Release Notes](https://osm-download.etsi.org/ftp/osm-15.0-fifteen/OSM_Release_FIFTEEN_Release_Notes.pdf).

-->

**OSM in Practice**:

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

- MINIMUM: 2 CPUs, 8 GB RAM, 50GB disk and a single interface with Internet access

- Base image: Ubuntu22.04

  - [Ubuntu22.04 cloud image (64-bit variant required)](https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-disk-kvm.img)

  - [Ubuntu22.04 server image (64-bit variant required)](http://releases.ubuntu.com/22.04/)

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-14.0-fourteen/install_osm.sh

wget https://osm-download.etsi.org/ftp/osm-15.0-fifteen/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-14.0-fourteen/install_osm.sh

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 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:

```bash

./install_osm.sh --k8s_monitor

./install_osm.sh --juju --lxd

```

#### Other installation options

- An additional installation option is the [Charmed Installation](03-installing-osm.md#charmed-installation) which will install OSM on Kubernetes with charms.

- For other special installation options, please refer to the [specific chapter on installation options](03-installing-osm.md).

For other special installation options, please refer to the [specific chapter on installation options](03-installing-osm.md).

### Checking your installation

### 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/ReleaseFOURTEEN/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/ReleaseFIFTEEN/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/ReleaseFOURTEEN/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/ReleaseFIFTEEN/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/ReleaseFOURTEEN/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/ReleaseFIFTEEN/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 [VNF data model](https://osm-download.etsi.org/repository/osm/debian/ReleaseFOURTEEN/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/ReleaseFIFTEEN/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/ReleaseFOURTEEN/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/ReleaseFIFTEEN/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|14.0.0|User Login|1|msg=User Logged In, Project\=admin Outcome\=Success suser=admin

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

```

### Audit Logs Prefixes

sudo apt-get install -y python3 python3-dev python3-pip

# Add OSM debian repo

curl -q -o OSM-ETSI-Release-key.gpg https://osm-download.etsi.org/repository/osm/debian/ReleaseFOURTEEN/OSM%20ETSI%20Release%20Key.gpg

curl -q -o OSM-ETSI-Release-key.gpg https://osm-download.etsi.org/repository/osm/debian/ReleaseFIFTEEN/OSM%20ETSI%20Release%20Key.gpg

sudo apt-key add OSM-ETSI-Release-key.gpg

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

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

sudo apt-get update

# Install OSM IM and osmclient packages from deb repo

# Upgrade pip to the latest version (with sudo, to install it globally for all users)

sudo -H python3 -m pip install -U pip

# Decide which version to use (e.g., v14.0)

export OSM_CLIENT_VERSION=v14.0

# Decide which version to use (e.g., v15.0)

export OSM_CLIENT_VERSION=v15.0

# Install OSM IM and its dependencies via pip (installed with sudo, to install it globally for all users)

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

sudo -H python3 -m pip install -U pip

# Decide which version to use (e.g., v43.0)

export OSM_CLIENT_VERSION=v14.0

export OSM_CLIENT_VERSION=v15.0

# Install OSM IM and its dependencies via pip (installed with sudo, to install it globally for all users)

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

# Upgrade pip to the latest version (with sudo, to install it globally for all users)

sudo -H python3 -m pip install -U pip

# Decide which version to use (e.g., v14.0)

export OSM_CLIENT_VERSION=v14.0

# Decide which version to use (e.g., v15.0)

export OSM_CLIENT_VERSION=v15.0

# Install OSM IM and its dependencies via pip (installed with sudo, to install it globally for all users)

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

# Upgrade pip to the latest version (with sudo, to install it globally for all users)

python -m pip install -U pip

# Decide which version to use (e.g., v14.0)

export OSM_CLIENT_VERSION=v14.0

# Decide which version to use (e.g., v15.0)

export OSM_CLIENT_VERSION=v15.0

# Clone IM repo and checkut the desired version

git clone https://osm.etsi.org/gerrit/osm/IM