As you can see, a list of "NFVI metrics" is defined first at the VDU level, which contains an ID and the corresponding normalized metric name (in this case, `cpu_utilization` and `average_memory_utilization`). Normalized metric names are: `cpu_utilization`, `average_memory_utilization`, `disk_read_ops`, `disk_write_ops`, `disk_read_bytes`, `disk_write_bytes`, `packets_received`, `packets_sent`, `packets_out_dropped`, `packets_in_dropped`
Not all metrics can be collected from all types of VIMs, the following table shows which metrics are supported by each type of VIM:
| Metric | Openstack | Azure | GCP |
| ------ |:---------:|:-----:|:-----:|
| cpu_utilization | X | X | X |
| average_memory_utilization | X || X |
| disk_read_ops | X | X | X |
| disk_write_ops | X | X | X |
| disk_read_bytes | X | X | X |
| disk_write_bytes | X | X | X |
| packets_in_dropped | X |||
| packets_out_dropped | X |||
| packets_received | X || X |
| packets_sent | X || X |
Available attributes and values can be directly explored at the [OSM Information Model](11-osm-im.md). A complete VNFD example can be downloaded from [here](https://osm.etsi.org/gitlab/vnf-onboarding/osm-packages/-/blob/master/hackfest_basic_metrics_vnf).
##### VMware vCD specific notes (OLD)
...
...
@@ -1699,7 +1714,21 @@ osm repo-show bitnami
### KNF Service on-boarding and instantiation
KNFs can be on-boarded using Helm Charts or Juju Bundles. In the following section is shown an example with Helm Chart and for Juju Bundles.
KNFs can be on-boarded using Helm Charts or Juju Bundles. In this section, examples with Helm Chart and Juju Bundles are shown.
#### Note about deprecation of Helm v2
Helm v2 has been deprecated since 2020. Starting from OSM Release FIFTEEN, OSM no longer supports Helm v2. If the end user tries to deploy a KNF using Helm v2, the following error will be found:
```log
ERROR: Error 422: {
"code": "UNPROCESSABLE_ENTITY",
"status": 422,
"detail": "Error in pyangbind validation: {'error-string': 'helm_version must be of a type compatible with enumeration', 'defined-type': 'kdu:enumeration', 'generated-type': 'YANGDynClass(base=RestrictedClassType(base_type=six.text_type, restriction_type=\"dict_key\", restriction_arg={\\'v3\\': {}},), default=six.text_type(\"v3\"), is_leaf=True, yang_name=\"helm-version\", parent=self, choice=(\\'kdu-model\\', \\'helm-chart\\'), path_helper=self._path_helper, extmethods=self._extmethods, register_paths=True, namespace=\\'urn:etsi:osm:yang:augments:kdu\\', defining_module=\\'kdu\\', yang_type=\\'enumeration\\', is_config=True)'}"
}
```
If you are the KNF provider and want to upgrade a helm chart from v2 to v3, follow the [official documentation](https://helm.sh/docs/topics/v2_v3_migration/)
#### KNF Helm Chart
...
...
@@ -2009,6 +2038,21 @@ __Step 2: See the notification in notification receiver.__
- Support for subscription and notification for VNFD.
- Cache to store subscribers.
## How to cancel an ongoing operation over a NS
The OSM client command `ns-op-cancel` allows to cancel any ongoing operation of Network Service. For instance, to cancel the instantiation of a NS execute the following steps:
1. Create the NS with `osm ns-create` and save the Network Service ID (NS_ID)
2. Obtain the Operation ID of the NS instantiation with `osm ns-op-list NS_ID`
3. Cancel the operation with `osm ns-op-cancel OP_ID`
4. The NS will be in `FAILED_TEMP` status.
Be aware that resources created before the cancellation will not be rolled back and the Network Service could be unhealthy.
If some operation is blocked due to an ungraceful restart of LCM module, you can use this command to delete the operation and unblock the Network Service.
Queued (unstarted) operations can also be deleted with this command.
## 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.
...
...
@@ -2144,6 +2188,42 @@ virtual-link-connectivity:
ip-address: 192.168.1.20
```
### How to Launch NS with Dual Stack IP (IPv4/IPv6) using SOL003 VNFM Interface
First, use API endpoint `/osm/vnflcm/v1/vnf_instances` to create a VNF object with a POST message, providing all the details mentioned in below sample payload. Make sure to add "ip-address" key and value with dual stack IP addresses. Behind the scenes, this creates a VNF and a NS package in OSM.
Then, use instantiation API `/osm/vnflcm/v1/vnf_instances/<vnfId>/instantiate` to launch the NS. Mention all the details in payload as shown in below sample.
SFC has the ability to cause network packet flows to route through a network via a path other than the one that would be chosen by routing table lookups on the packet’s destination IP address.
...
...
@@ -2244,8 +2324,10 @@ Launch the NS:
```bash
osm ns-create --ns_name sfc --nsd_name sfc_nsd --vim_account <VIM_ACCOUNT_NAME>|<VIM_ACCOUNT_ID>
osm ns-list
```
#### Testing
```bash
# In src_vnf and dest_vnf install the netcat
sudo apt install netcat -y
...
...
@@ -2257,3 +2339,4 @@ sudo nc -l -p 90
# In src_vnf, run the below command. This command will connect to the server at <dest_vnf> ip-address on port 90
sudo nc <dest_vnf_ip_address> 90
# All the packets from src vnf to dest vnf should route only through the mid vnf.
@@ -621,7 +621,7 @@ In order to add a repo, the user should invoke the following command:
osm repo-add <name> <URI> type:<chart|bundle>
```
Where the type of repo should be either `chart` for applications based on Helm Charts, or `bundle` for applications based in Juju bundles for K8s.
Where the type of repo should be either `chart` for applications based on Helm Charts, or `bundle` for applications based in Juju bundles for K8s. If the repo is a helm OCI registry, add the flag `--oci` and provide credentials using `--user` and `--password`.
This call will trigger the following actions in OSM:
@@ -108,6 +108,21 @@ The following figure illustrates graphically the specific workflows for metric a
Regarding to resource consumption metrics, three types of VIM are currently supported: Openstack (Gnocchi and Ceilometer back-ends), Azure and GCP. The metrics that OSM can collect from the VNFs deployed in those VIMs are shown in the table below:
| Metric | Openstack | Azure | GCP |
| ------ |:---------:|:-----:|:-----:|
| osm_cpu_utilization | X | X | X |
| osm_average_memory_utilization | X || X |
| osm_disk_read_ops | X | X | X |
| osm_disk_write_ops | X | X | X |
| osm_disk_read_bytes | X | X | X |
| osm_disk_write_bytes | X | X | X |
| osm_packets_in_dropped | X |||
| osm_packets_out_dropped | X |||
| osm_packets_received | X || X |
| osm_packets_sent | X || X |
The metrics, as acquired by OSM, might not be useful per-se, since they are not related to OSM objects. For instance, the VM status or the VM resource consumption metrics are only useful when they relate to a VNF instance or a NS instance. [Prometheus recording rules](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/) allow to derive metrics from existing metrics, computing them and saving the result as a new set of time series. The following figure shows a screenshot of the metrics derived in Prometheus.
