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.
Release ELEVEN brings a number of improvements over previous releases. For the full list of new features, please refer to the [Release Notes](https://osm.etsi.org/wikipub/images/9/95/OSM_Release_ELEVEN_-_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 TWELVE is the second LTS release of ETSI OSM, providing two years of continuous support with bug fixes and security patches. This is one of the most prolific releases of ETSI OSM, including significant improvements in many key areas. For the full list of new features, please refer to the [Release Notes](https://osm-download.etsi.org/ftp/osm-12.0-twelve/OSM_Release_TWELVE_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).
**OSM in Practice**:
@@ -38,7 +38,7 @@ All you need to run OSM is a single server or VM with the following requirements
Once you have prepared the host with the previous requirements, all you need to do is:
@@ -128,7 +128,6 @@ Before proceeding, make sure that you have a site with a VIM configured to run w
-**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](04-vim-setup.md#amazon-web-services-aws)
-**VMware vCloud Director.** Check the following link to learn how to configure VMware VCD to be used by OSM: [Configuring VMware vCloud Director](04-vim-setup.md#vmwares-vcloud-director)
-**OpenVIM.** Check the following link to know how to install and use openvim for OSM: [OpenVIM installation](13-openvim-installation.md). OpenVIM must run in 'normal' mode (not test or fake) to have real virtual machines reachable from OSM.
-**Eclipse fog05** Check the following link to learn how to configure Eclipse fog05 to be used by OSM: [Configuring Eclipse fog05 for OSM](04-vim-setup.md#fog05)
OSM can manage external SDN controllers to perform the dataplane underlay network connectivity on behalf of the VIM. See [EPA and SDN assist](04-vim-setup.md#advanced-setups-for-high-io-performance-epa-and-sdn-assist)
--description"Openvim site"--tenant osm --user dummy --password dummy
```
#### Eclipse fog05 site
- Execute the following command, using the appropriate parameters (e.g. runtime supported: "hypervisor", cpu architecture: "arch", user: "XXX", password: "YYY")
```bash
osm vim-create --name fos --auth_url <rest proxy ip>:8080 --account_type fos --tenant osm --user dummy --password dummy --config'{hypervisor: LXD}'
```
For advanced options, please refer to the [Configuring Eclipse fog05 for OSM](04-vim-setup.md#fog05).
As it can be seen above, there is a parameter called **`--config`** used to supply general configuration options, which can be used when creating the VIM target using the OSM client.
A number of configuration options are supported:
#### Configuration Options Reference
-`management_network_id`, `management_network_name`: VIM management network id/name to use for the management VLD of NS descriptors. By default it uses same vim network name as VLD name. It can be set also at instantiation time.
-`security_groups`: To be used for the deployment
@@ -233,6 +233,8 @@ If not, use a path of an existing image at host where OSM is running
### Adding vCD as VIM target to OSM
**Note: Be aware that vCD connector for VMware vCloud Director is no longer maintained and is offered as best-effort code with no guarantees. No bug fixes will be provided from the community on vCD connector. If you are interested in contributing and leading its evolution, please feel free to contact TSC mailing list [OSM_TECH@list.etsi.org](https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=OSM_TECH@list.etsi.org). or RO MDL via Slack.**
-`<image_project>:image:<image>`: to get a specific image `<image>` in the project `<image_project>` (e.g. `ubuntu-os-cloud:image:ubuntu-1804-bionic-v20210928`)
-`<image_project>:<image>`: equivalent to `<image_project>:image:<image>` (e.g. `ubuntu-os-cloud:ubuntu-1804-bionic-v20210928`)
## Eclipse fog05
Eclipse fog05 (can be read as _fog-O-five_ or _fog-O-S_) is a different kind of VIM, designed to manage a fog/edge environment, thus it is completely distributed (no controller/master node) and pluggable, and available as FOSS from Eclipse: <https://github.com/eclipse-fog05>
It stores information in a distributed key-value store that then is able to provide location transparency to the user, and all the state information are stored in it.
#### Upload Images
Image registration can be done by using the python rest API. First generate the descriptor of your image:
```json
{
"name":"example-image",
"uri":"lxd://alpine/edge",
"checksum":"<sha256sum of image file",
"format":"<image format eg. qcow2, iso, tar.gz>"
}
```
the using the python api the upload of the image can be done:
```python
>>>api.image.add(img_descriptor)
```
### Adding Eclipse fog05 as VIM target of OSM
Alike the rest of VIM types, you should provide the appropiate paramenters in `--config` when creating the VIM target.
```bash
osm vim-create --name fos --auth_url <zenoh server ip>:7447 --account_type fos --tenant osm --user dummy --password dummy --config'{hypervisor: LXD}'
```
The following configuration can be added:
-`arch`: cpu architecture used when creating the VDUs for this VIM account eg. x86\_64, aarch64, default is x86\_64.
-`hypervisor`: hypervisor supported by this VIM account, can be one of: LXD, KVM, BARE, DOCKER, ROS2, at least one node of the system as to be able to manage the selected hypervisor, default and supported is LXD.
#### VLAN configuration (optional)
If you want your fog05 installation to be able to use VLANs for virtual networks instead of overlay VxLANs you need to change the configuration on all nodes. You need to update the configuration file `/etc/fos/plugins/linuxbridge/linuxbridge_plugin.json`.
```json
{
"name":"linuxbridge",
"version":1,
"uuid":"d42b4163-af35-423a-acb4-a228290cf0be",
"type":"network",
"requirements":[
"jinja2"
],
"description":"linux Bridge network plugin",
"configuration":{
"ylocator":"tcp/<your zenoh ip>:7447",
"nodeid":"<your node id>",
"dataplane_interface":"<interface for overlay networks>",
"use_vlan":true,
"vlan_interface":"<interface for vlans>",
"vlan_range":[
<startvlanid>,
<endvlanid>
]
}
}
```
After that you have to restart the fog05 network and runtime plugins in the nodes.
#### Example NS
Here you can find and example of network service that can be instantiated to the Eclipse fog05 VIM using OSM. The network service is composed by a single VNF based on an Alpine Linux LXD image.
**`alpine-vnfd.yaml`**:
```yaml
vnfd:vnfd-catalog:
vnfd:
-id:alpine_vnfd
name:alpine_vnf
short-name:alpine_vnf
description:Simple VNF example with a Alpine
vendor:OSM
version:'1.0'
logo:alpine.jpg
connection-point:
-name:eth0
type:VPORT
vdu:
-id:alpine_vnfd-LXD
name:alpine_vnfd-LXD
description:alpine_vnfd-LXD
count:1
vm-flavor:
vcpu-count:1
memory-mb:256
storage-gb:1
image:alpine-lxd
interface:
-name:eth0
type:EXTERNAL
virtual-interface:
type:VIRTIO
bandwidth:'0'
vpci:0000:00:0a.0
external-connection-point-ref:eth0
mgmt-interface:
cp:eth0
```
**`alpine-ns.yaml`**:
```yaml
nsd:nsd-catalog:
nsd:
-id:alpine_nsd
name:alpine_ns
short-name:alpine_ns
description:Generated by OSM pacakage generator
vendor:OSM
version:'1.0'
constituent-vnfd:
-member-vnf-index:1
vnfd-id-ref:alpine_vnfd
vld:
### Networks for the VNFs
-id:alpine_nsd_vld1
name:alpine_nsd_vld1
short-name:alpine_nsd_vld1
type:ELAN
mgmt-network:'true'
vnfd-connection-point-ref:
-member-vnf-index-ref:1
vnfd-id-ref:alpine_vnfd
vnfd-connection-point-ref:eth0
```
## What if I do not have a VIM at hand? Use of sandboxes
REMOVE_VNF operation involves terminating a running VNF instance. This operation could terminate one VNF instance at a time from a NS instance. If termination is invoked for a VNF and it is the last VNF instance in a NS instance, then it cannot be terminated.
The Remove VNF operation currently does not support VNFs that include charms.
- Fill in the form by selecting 'REMOVE_VNF' from the dropdown of 'Update Type' and the member vnf index of the VNF to be terminated and click 'Apply'
- A warning message is displayed, click 'Terminate VNF' to proceed
- Click 'Cancel' to cancel the termination operation
#### Redeploying a VNF from UI
- Go to 'NS Instances' on the 'Instances' menu to the left
- Next to the NS instance which the VNF to be redeployed is a part of, click on the 'Action' button.
- From the dropdown actions, click on 'NS Update'
- Fill in the form by selecting the following,
- 'CHANGE_VNFPKG' from the dropdown of 'Update Type'
- The member vnf index of the VNF to be updated
- VNFDId for the update (Should be same as the vnfd-id of the VNF to be updated)
- Finally, click 'Apply'
- A warning message is displayed, click 'Redeploy and Update' to proceed
- Click 'Cancel' to cancel the update operation
## Advanced instantiation: using instantiation parameters
OSM allows the parametrization of NS or NSI upon instantiation (Day-0 and Day-1), so that the user can easily decide on the key parameters of the service without any need of changing the original set of validated packages.
@@ -522,6 +598,20 @@ These charms can run with three scopes:
- VNF: running globally for the VNF, for the management VDU that represents it.
- NS: running for the whole NS, after VNFs have been configured, to handle interactions between them.
Depending on the scope of charms, the charm application naming differs:
-**The VNF level** charm application name is prepared by combining the relevant execution environment name and vnf-profile-id.
-**The VDU level** charm application name includes vdu-profile-id as an identifier together with the relevant execution environment name and vnf-profile-id that it belongs.
-**The NS level** charm application name is identified with the charm name.
The structure of charm application name makes the charm more apparent. Besides, it makes the VDU/KDU more visible by looking through the related charm. The structure of charm application names which are limited with 50 characters, are described below according to scope of charms:
@@ -1070,6 +1160,76 @@ sudo service haproxy restart
Any of the VMs can be accessed through SSH (credential: `ubuntu`/`osm2021`) to further monitor (with `htop`, for example), and there is an HAProxy UI at port `http://[HAProxy_IP]:32700` (credential: `osm`/`osm2018`)
- Healing descriptors can be included and be tied to automatic reaction to VM metric thresholds.
- An internal alarm manager has been added to MON through the 'mon-evaluator' module, so VM metrics can trigger threshold-violation alarms when VM is in `ERROR/DELETE` state and perform healing actions.
#### Healing Descriptor
The healing descriptor is part of a VNFD. Like the example below shows, it mainly specifies:
- The VDU to be healed (`healing-policy:vdu-id`)
- The healing recovery option (`action-on-recovery`)
- The minimum time it should pass between healing operations (`cooldown-time`)
osm ns-create --ns_name heal --nsd_name autoheal_nsd --vim_account <VIM_ACCOUNT_NAME>|<VIM_ACCOUNT_ID>
osm ns-list
osm ns-show heal
```
#### Testing:
1. To ensure NS is instantiated successfully, check metrics at Prometheus, visit `http://[OSM_IP]:9091` and look for `osm_vm_status`. Metric value should be '1'.
2. Run the following openstack commands to induce and error or delete a VM:
```bash
# To test healing in error state, induce error state in vm
openstack server set--state error <server-id>
# To test healing in deleted state, delete the vm
openstack server delete <server-id>
```
3. Check metrics at Prometheus, visit `http://[OSM_IP]:9091` and look for `osm_vm_status`. Metric value should be '0'.
4. Heal operation will be triggered at POL and VM respawn will happen.
## Using Network Slices
In order to illustrate better how network slicing works in OSM, it will be discussed in the context of a running example.
@@ -1444,8 +1604,8 @@ KNFs can be on-boarded using Helm Charts or Juju Bundles. In the following secti
Once the cluster is attached to your OSM, you can work with KNF in the same way as you do with any VNF. You can onboard them. For instance, you can use the example below of a KNF consisting of a single Kubernetes deployment unit based on OpenLDAP helm chart.
@@ -1697,6 +1857,43 @@ __Step 2: See the notification in notification receiver.__
- Support for subscription and notification for VNFD.
- Cache to store subscribers.
## Start, Stop and Rebuild operations over a VDU of a running VNF instance
These three operations involves starting , stopping, and rebuilding of a VDU on a running VNF instance by using the NGUI.
OSM allows these three operations over VDUs for all supported VIMs.
### Start Operation:
Start operation lets you start one VNF instance at a time and that instance should be in `shutoff` state.
### Stop Operation:
Stop operation lets you stop one VNF instance at a time and that instance should be in `running` state.
### Rebuild Operation:
Rebuild operation lets you rebuild one VNF instance at a time and in this operation, the instance can be in either `running` or `shutoff` state.
### Additional Notes
- Each operation is executed independently and only one at a time.
- In the rebuild operation, we are not deleting the target VDU nor we are recreating it. The VDU will be rebuilt by using the existing image, so actual properties of the VDU are preserved like name and IP addresses.
### How to perform operation from UI
From OSM's user action menu select the operation (start, stop, rebuild), select the Member VNF index, select the VDU id and Count Index for the target VDU, then select apply. This will trigger the operation.
#### Future roadmap
Implementation of day-1 operation for rebuild operation is in roadmap.
## Migrating VDUs in a Network Service
OSM allows the migration of VDUs, that are part of a VNF, across compute hosts.
@@ -1731,4 +1928,3 @@ From the UI:
- Fill in the form, adding at least the member vnf index:
