From 61640d4481aa184fae0cb4b73ac4da4736dceddc Mon Sep 17 00:00:00 2001 From: ramonsalguer Date: Sun, 7 Apr 2019 19:46:07 +0200 Subject: [PATCH 1/6] Review of Chapter 0 --- 00-introduction.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/00-introduction.md b/00-introduction.md index d24d955..94e36ad 100644 --- a/00-introduction.md +++ b/00-introduction.md @@ -1,18 +1,17 @@ # Introduction -The complete onboarding process implies producing a VNF Package that will be part of the OSM catalogue for its inclusion in a Network Service. +The complete onboarding process implies producing a VNF Package that will be part of the OSM catalogue for its inclusion in a Network Service. The onboarded VNF should aim to fulfill the lifecycle stages that the NFV MANO layer should be able to automate. Hence, the resulting package, should include all the requirements, instructions and elements to achieve basic instantiation (a.k.a. "Day-0"), service initialization (a.k.a. "Day-1") and runtime operations (a.k.a. "Day-2"). ![](assets/vnfonboarding.gif) -More information on the delimitation of these stages can be found in the [*OSM Scope and Functionality*](https://osm.etsi.org/wikipub/index.php/OSM_Scope_and_Functionality) document. +More information on the delimitation of these stages can be found in the [*OSM Scope and Functionality*](http://osm-download.etsi.org/ftp/Documentation/201902-osm-scope-white-paper/#!02-osm-scope-and-functionality.md) document. -As such, the document is structured in the following parts, providing guidelines for building the VNF Package to achieve each lifecycle stage sucessfully. +As such, the document is structured in the following parts, providing guidelines for building the VNF Package to achieve each lifecycle stage successfully. 1. Onboarding Requirements -1. Day 0: VNF Instantiation & management setup -1. Day 1: VNF Services initialization -1. Day 2: VNF Runtime operations -1. Known issues - +2. Day 0: VNF Instantiation & management setup +3. Day 1: VNF Services initialization +4. Day 2: VNF Runtime operations +5. Known issues -- GitLab From 4e5a71b5717e95f0fd7dc9035cfdc2cee39cb43b Mon Sep 17 00:00:00 2001 From: ramonsalguer Date: Sun, 7 Apr 2019 20:10:04 +0200 Subject: [PATCH 2/6] Review of Chapter 1 --- 01-requirements.md | 204 +++++++++++++++++++++++---------------------- 1 file changed, 106 insertions(+), 98 deletions(-) diff --git a/01-requirements.md b/01-requirements.md index 36e1905..a404958 100644 --- a/01-requirements.md +++ b/01-requirements.md @@ -1,6 +1,6 @@ # Onboarding Requirements -To achieve the onboarding of each lifecycle stage successfully, the following specific requirements of the VNF must be collected. +To achieve the onboarding of each lifecycle stage successfully, the following specific requirements of the VNF must be collected. ## Day 0 requirements @@ -8,69 +8,73 @@ The main objetive of Day 0 is to instantiate the VNF and establish management ac 1. **Description of each VNF component**: The main function of every VNF component (VDU) should be clearly described in order to ease the understanding of the VNF. For example: - | VDU | Description | - |:------:|:------------------------------------| - | vLB | External frontend and load balancer | - | uMgmt | Universal VNF Manager (EM) | - | sBE | Service Backend of the platform | +| VDU | Description | +|:------:|:------------------------------------| +| vLB | External frontend and load balancer | +| uMgmt | Universal VNF Manager (EM) | +| sBE | Service Backend of the platform | 2. **Defining NFVI basic requirements**: Basic requirements include the number of vCPUs, RAM GBs and disk GBs per component, as well as any other resource that the VNF components need from the physical infrastructure. For example: - | VDU | vCPU | RAM (GB) | Storage (GB) | External volume? | - |:-----:|:----:|:--------:|:------------:|:----------------:| - | vLB | 2 | 4 | 10 | N | - | uMgmt | 1 | 1 | 2 | N | - | sBE | 2 | 8 | 10 | Y | +| VDU | vCPU | RAM (GB) | Storage (GB) | External volume? | +|:-----:|:----:|:--------:|:------------:|:----------------:| +| vLB | 2 | 4 | 10 | N | +| uMgmt | 1 | 1 | 2 | N | +| sBE | 2 | 8 | 10 | Y | 3. **Defining NFVI EPA requirements**: Enhanced Platform Awareness characteristics should be defined in case the VNF requires 'higher than default' performance capabilities or any particular hardware architecture from the NFVI. Popular EPA attributes include: - * Compute performance attributes: - * Hypervisor type / version - * CPU Pinning - * NUMA Topology Awareness - * Memory Page Size - * Data plane performance attributes: - * SR-IOV / PCI-Passthrough - * OVS-DPDK Acceleration - * Host attributes: - * CPU Model, Architecture & Vendor - * CPU Socket & Core count - - For example, vLB and sBE VDU could require: - * KVM 2.11+ - * 2 dedicated vCPUs - * Large size memory pools - * eth1 and eth2 interfaces should use SR-IOV - * CPU should be Intel x86 with no further restrictions - + - Compute performance attributes: + - Hypervisor type / version + - CPU Pinning + - NUMA Topology Awareness + - Memory Page Size + - Data plane performance attributes: + - SR-IOV / PCI-Passthrough + - OVS-DPDK Acceleration + - Host attributes: + - CPU Model, Architecture & Vendor + - CPU Socket & Core count + + For example, vLB and sBE VDU could require: + + - KVM 2.11+ + - 2 dedicated vCPUs + - Large size memory pools + - eth1 and eth2 interfaces should use SR-IOV + - CPU should be Intel x86 with no further restrictions 4. **Topology and management definition**: Ideally, a diagram should be used to quickly identify components and internal/external connections. - ![](assets/vnftopology1.png) +![](assets/vnftopology1.png) -5. **Images and cloud-init files**: The images for each component should be available in the format that corresponds to the main supported hypervisor. This image should contain the minimal configuration that makes it generic (not scenario-specific) and with **no hardcoded parameters** that are relevant to the service. Furthermore, cloud-init files can be used to inject this minimal configuration to the VNF. Some examples: +5. **Images and cloud-init files**: The images for each component should be available in the format that corresponds to the main supported hypervisor. This image should contain the minimal configuration that makes it generic (not scenario-specific) and with **no hardcoded parameters*- that are relevant to the service. Furthermore, cloud-init files can be used to inject this minimal configuration to the VNF. Some examples: - # Cloud-init using cloud-config format +```yaml +# Cloud-init using cloud-config format - #cloud-config - hostname: vnfc01 - chpasswd: { expire: False } - ssh_pwauth: True +#cloud-config +hostname: vnfc01 +chpasswd: { expire: False } +ssh_pwauth: True +``` - # Cloud-init using bash format for CentOS +```bash +# Cloud-init using bash format for CentOS - #!/bin/bash - hostnamectl set-hostname vnfc01 +#!/bin/bash +hostnamectl set-hostname vnfc01 - cat < /tmp/ipcfg - DEVICE=eth1 - BOOTPROTO=dhcp - HWADDR=00:19:D1:2A:BA:A8 - ONBOOT=yes - EOF +cat < /tmp/ipcfg +DEVICE=eth1 +BOOTPROTO=dhcp +HWADDR=00:19:D1:2A:BA:A8 +ONBOOT=yes +EOF - echo -y | cp /tmp/ipcfg /etc/sysconfig/network-scripts/ifcfg-eth0 - systemctl restart network +echo -y | cp /tmp/ipcfg /etc/sysconfig/network-scripts/ifcfg-eth0 +systemctl restart network +``` 6. **Identifying the need for instantiation parameters**: the VNF Day-0 configuration may require some parameters passed at instantiation time in order to fulfill the needs of the particular environment or of other VNFs in the Network Service. This parameters should be identified as early in the process as possible. @@ -80,82 +84,86 @@ The main objetive of Day 1 is to configure the VNF so it starts providing the ex 1. **Identifying dependencies between components**: this may be required to identify instantiation parameters or special timing requirements. Examples of dependencies between components include: - * Components needing parameters from other components of from the infrastructure to complete the parameters configuration. - * Components depending on others for their configuration to be initialized. + - Components needing parameters from other components of from the infrastructure to complete the parameters configuration. + - Components depending on others for their configuration to be initialized. 2. **Defining the required configuration for service initialization**: this initial configuration will run automatically after the VNF has been instantiated. It should activate the service that the VNF is supposed to deliver, and should be initially prepared in the language that the VNF supports. Once it's defined, it would need to be incorporated by the mechanism that the generic VNF Manager implements. For example: - # A Python script (NETCONF/YANG in the example) - - from ncclient import manager - import sys +```python +# A Python script (NETCONF/YANG in the example) - config = """ - - - ... - - - """ +from ncclient import manager +import sys - host = {'name':'VNF1','ip': '192.168.0.1'} - interface_list = ['eth1','eth2'] +config = """ + + + ... + + +""" - m = manager.connect(host=host['ip'],username='ws',password='ws') +host = {'name':'VNF1','ip': '192.168.0.1'} +interface_list = ['eth1','eth2'] - for interface in interface_list: - response = m.edit_config(target='candidate', config=config.format(interface=interface)) - commit = m.commit() - print(commit) +m = manager.connect(host=host['ip'],username='ws',password='ws') - m.close_session() +for interface in interface_list: + response = m.edit_config(target='candidate', config=config.format(interface=interface)) + commit = m.commit() + print(commit) - # An Ansible playbook (VyOS module in the example) +m.close_session() +``` - - hosts: all - tasks: - - name: Configure the VNF initial NAT Rules - vyos_config: - lines: - - set nat destination rule 1 inbound-interface eth0 - - set nat destination rule 1 destination port 80 - - set nat destination rule 1 protocol tcp - - set nat destination rule 1 translation address {{destination_ip}} +```yaml +# An Ansible playbook (VyOS module in the example) + +- hosts: all + tasks: + - name: Configure the VNF initial NAT Rules + vyos_config: + lines: + - set nat destination rule 1 inbound-interface eth0 + - set nat destination rule 1 destination port 80 + - set nat destination rule 1 protocol tcp + - set nat destination rule 1 translation address {{destination_ip}} +``` 3. **Identifying the need for instantiation parameters**: the VNF Day-1 configuration may require some parameters passed at instantiation time in order to fulfill the needs of the particular environment or of other VNFs in the Network Service. This parameters should be identified as early in the process as possible. ## Day 2 requirements -The main objetive of Day 2 is to be able to **re-configure** the VNF so its behavior can be modified during runtime, as well as being able to monitor its main KPIs., and run scaling and healing actions over it. +The main objetive of Day 2 is to be able to **re-configure*- the VNF so its behavior can be modified during runtime, as well as being able to monitor its main KPIs., and run scaling and healing actions over it. To achieve this, the main requirements are: 1. **Identifying dependencies between components**: this process may be required to identify if a VNF component requires a parameter coming from other component for fulfilling runtime operations successfully. - + 2. **Defining all possible configurations for runtime operations**: this set of configurations should be available to be triggered from the orchestrator during the VNF runtime, either manually by the operator, or automatically based on some state. Once this set of configurations have been defined, they would need to be incorporated by the mechanism that the generic VNF Manager implements. Just as in Day-1, the set of configurations can be provided by Python scripts, Ansible playbooks, VNF-specific commands run over SSH, REST API calls, or whatever the VNF makes available to expose its main operations. 3. **Defining key performance indicators**: the metrics that are relevant to the VNF should be specified, either if they are supposed to be collected from the infrastructure (through the VIM) or directly from the VNF (or its EM, through any API, MIB or command that the VNF exposes). Some examples include: - * Metrics typically collected from the VIM/NFVI: - * CPU Usage - * Memory Usage - * Network activity (bandwidth, drops, etc.) - * Storage consumption - * Metrics collected from the VNF/EM (examples): - * Active transactions/sessions/connections - * Active users - * Size of the database or a particular table - * Application status + - Metrics typically collected from the VIM/NFVI: + - CPU Usage + - Memory Usage + - Network activity (bandwidth, drops, etc.) + - Storage consumption + - Metrics collected from the VNF/EM (examples): + - Active transactions/sessions/connections + - Active users + - Size of the database or a particular table + - Application status 4. **Defining closed-loop operations**: Closed-loop operations are actions triggered by the status of a particular metric. Main use cases include: - * Auto-scaling: a VNF component scales horizontally (out/in) to match the current demand. Some typical definitions that must be clear are: - * How the VNF will load-balance the traffic once it scales. - * Which components should scale, in what quantity, and based on which metric threshold or status. - * How much time should the system wait between scaling requests. - * Auto-healing: a VNF component is re-instantiated, reloaded or reconfigured based on a service status. Some typical definitions that must be clear are: - * Under which conditions should the system trigger an auto-healing action. - * Which elements should be affected and at what level (reinstantiation, hard-reload, soft-reload, process restart, etc.) + - Auto-scaling: a VNF component scales horizontally (out/in) to match the current demand. Some typical definitions that must be clear are: + - How the VNF will load-balance the traffic once it scales. + - Which components should scale, in what quantity, and based on which metric threshold or status. + - How much time should the system wait between scaling requests. + - Auto-healing: a VNF component is re-instantiated, reloaded or reconfigured based on a service status. Some typical definitions that must be clear are: + - Under which conditions should the system trigger an auto-healing action. + - Which elements should be affected and at what level (reinstantiation, hard-reload, soft-reload, process restart, etc.) ```diff - NEXT SECTIONS ARE WORK IN PROGRESS -- GitLab From c1c5562159080bc39109d179efdb495ab28bc7ee Mon Sep 17 00:00:00 2001 From: ramonsalguer Date: Sun, 7 Apr 2019 20:18:13 +0200 Subject: [PATCH 3/6] Review of Chapter 2 --- 02-day0.md | 77 +++++++++++++++++++++++++++--------------------------- 1 file changed, 38 insertions(+), 39 deletions(-) diff --git a/02-day0.md b/02-day0.md index 68115bd..16b3370 100644 --- a/02-day0.md +++ b/02-day0.md @@ -8,59 +8,58 @@ The way to achieve this in OSM is to prepare the descriptor so that it accuratel ## Day 0 Onboarding Guidelines -### 1. Building the initial package +### Building the initial package The most straightforward to build a VNF package from scratch, is to use the existing script available a the OSM Devops repository. From a Linux/UNIX systems: -* Clone the OSM DevOps repository and access the tools folder. +#### Clone the OSM DevOps repository and access the tools folder. - ``` - git clone https://osm.etsi.org/gerrit/osm/devops.git` - cd devops/descriptor-packages/tools - ``` +```bash +git clone https://osm.etsi.org/gerrit/osm/devops.git` +cd devops/descriptor-packages/tools +``` -* Run the generator script with the desired options. +#### Run the generator script with the desired options. - `./generate_descriptor_pkg.sh [options] [name]` +`./generate_descriptor_pkg.sh [options] [name]` - Most common options are: +Most common options are: - | Parameter | Scope | Description | Values | - |:-----------------:|:-------:|:-------------------------------------------:|:----------:| - | -t | package | descriptor type | vnfd | nsd | - | -a | package | create package for the descriptor | - | - | -N | package | keep folder after tar is built | - | - | -c | package | create folder structure inside package | - | - | -d | package | destination of the folder | path | - | --nsd | package | create folder structure for NSD as well | - | - | --image | vdu | image name | name | - | --vcpu | vdu | vCPU number | # | - | --memory | vdu | RAM size | [mb] | - | --storage | vdu | disk size | [gb] | - | --cloud-init-file | vdu | cloud-init file name | name | - | --interfaces | vdu | interface number (additional to management) | # | - | --vendor | vnf | vendor name | name | +| Parameter | Scope | Description | Values | +|:-----------------:|:-------:|:-------------------------------------------:|:----------:| +| -t | package | descriptor type | vnfd | nsd | +| -a | package | create package for the descriptor | - | +| -N | package | keep folder after tar is built | - | +| -c | package | create folder structure inside package | - | +| -d | package | destination of the folder | path | +| --nsd | package | create folder structure for NSD as well | - | +| --image | vdu | image name | name | +| --vcpu | vdu | vCPU number | # | +| --memory | vdu | RAM size | [mb] | +| --storage | vdu | disk size | [gb] | +| --cloud-init-file | vdu | cloud-init file name | name | +| --interfaces | vdu | interface number (additional to management) | # | +| --vendor | vnf | vendor name | name | -* For example: +For example: - ``` - ./generate_descriptor_pkg.sh -t vnfd -N -c -d /home/ubuntu \ - -a --image haproxy_ubuntu --vcpu 2 --memory 4096 --storage 10 \ - --cloud-init-file init_lb --interfaces 2 --vendor ACME vLB - ``` +```bash +./generate_descriptor_pkg.sh -t vnfd -N -c -d /home/ubuntu \ +-a --image haproxy_ubuntu --vcpu 2 --memory 4096 --storage 10 \ +--cloud-init-file init_lb --interfaces 2 --vendor ACME vLB +``` - will create: +will create: - * vLB_vnfd → VNFD Folder - * vLB_vnfd.tar.gz → VNFD Package +- `vLB_vnfd` → VNFD Folder +- `vLB_vnfd.tar.gz` → VNFD Package -### 2. Building and adding cloud-init scripts +### Building and adding cloud-init scripts -### 3. Guidelines for EPA requirements +### Guidelines for EPA requirements -### 4. Adding other artifacts to the package +### Adding other artifacts to the package -### 5. Packaging the VNF for testing - -### 6. Testing the VNF Package +### Packaging the VNF for testing +### Testing the VNF Package -- GitLab From 67047a2fbf040cea061fbb01a7117df6e484c97f Mon Sep 17 00:00:00 2001 From: ramonsalguer Date: Sun, 7 Apr 2019 20:19:02 +0200 Subject: [PATCH 4/6] Review of Chapter 3 --- 03-day1.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/03-day1.md b/03-day1.md index e6785ff..106b12d 100644 --- a/03-day1.md +++ b/03-day1.md @@ -9,7 +9,6 @@ The main mechanism to achieve this in OSM is to build a Proxy Charm and include ## Day 1 Onboarding Guidelines 1. Adding Day-1 primitives to the descriptor -1. Building a Proxy Charm -1. Packaging the VNF for testing -1. Testing the VNF Package - +2. Building a Proxy Charm +3. Packaging the VNF for testing +4. Testing the VNF Package -- GitLab From 337eef43747f9acd47e289156f3c486e77daa9b0 Mon Sep 17 00:00:00 2001 From: ramonsalguer Date: Sun, 7 Apr 2019 20:19:44 +0200 Subject: [PATCH 5/6] Review of Chapter 4 --- 04-day2.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/04-day2.md b/04-day2.md index b970bc8..ffd34cd 100644 --- a/04-day2.md +++ b/04-day2.md @@ -2,16 +2,15 @@ ## Description of this phase -The objective of this section is to provide the guidelines for including all the necessary elements in the VNF Package so that it can be operated at runtime. Typical operations include reconfiguration of services, KPI monitoring and the enablement of automatic, closed-lopp operations triggered by monitored status. +The objective of this section is to provide the guidelines for including all the necessary elements in the VNF Package so that it can be operated at runtime. Typical operations include reconfiguration of services, KPI monitoring and the enablement of automatic, closed-loop operations triggered by monitored status. The main mechanisms to achieve reconfiguration in OSM is to build a Proxy Charm and include it in the descriptor, while monitoring and VNF-specific policy management can be achieved by specifying the requirements at the descriptor (modifying monitored indicators and policies at runtime is not supported in OSM as of the present release) ## Day 2 Onboarding Guidelines 1. Adding Day-2 primitives to the descriptor -1. Building a Proxy Charm -1. Adding monitoring parameters -1. Adding closed-loop operations -1. Packaging the VNF for testing -1. Testing the VNF Package - +2. Building a Proxy Charm +3. Adding monitoring parameters +4. Adding closed-loop operations +5. Packaging the VNF for testing +6. Testing the VNF Package -- GitLab From 91be26a7dac99fc620d1f9668bf8295c3054e055 Mon Sep 17 00:00:00 2001 From: ramonsalguer Date: Sun, 7 Apr 2019 20:20:47 +0200 Subject: [PATCH 6/6] Review of Chapter 5 --- 05-knownissues.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/05-knownissues.md b/05-knownissues.md index 3d83e85..4491020 100644 --- a/05-knownissues.md +++ b/05-knownissues.md @@ -4,5 +4,5 @@ ### v5.0.5 -* Instantiation 'additional' parameters can't be passed with the config object through the dashboard. Being addressed by [this fix.](https://osm.etsi.org/gerrit/#/c/7357/) -* Cloud-init will not allow parameter names with hyphens due to Jinja2 (Python Identifiers) implementation, but the error is misleading. Being addressed through [this bug](https://osm.etsi.org/bugzilla/show_bug.cgi?id=667) \ No newline at end of file +- Instantiation 'additional' parameters can't be passed with the config object through the dashboard. Being addressed by [this fix.](https://osm.etsi.org/gerrit/#/c/7357/) +- Cloud-init will not allow parameter names with hyphens due to Jinja2 (Python Identifiers) implementation, but the error is misleading. Being addressed through [this bug](https://osm.etsi.org/bugzilla/show_bug.cgi?id=667) \ No newline at end of file -- GitLab