OSM Public Wiki - User contributions [en]

Logs and troubleshooting (Release TWO)

2017-04-28T20:36:25Z

Chamarty:

__TOC__

=Logs=
==UI logs==

The server-side UI logs can be obtained on the SO-ub container at:
<pre>
/usr/rift/usr/share/rw.ui/skyquake/err.log
/usr/rift/usr/share/rw.ui/skyquake/out.log
</pre>

Client side UI logs can be obtained in the Developer Console in a browser.

==SO logs==

SO logs can be obtained on the SO-ub container at:
<pre>
/var/log/rift/rift.log
</pre>

==RO logs==
RO logs can be obtained on the RO container at:
<pre>/var/log/osm/openmano.log</pre>

Log file and log level (''debug'' by default) can be set at file:
<pre>/etc/osm/openmanod.cfg</pre>

==VCA logs==

=Troubleshooting=

==Troubleshooting UI==

===UI status===
* The status of the UI process can be checked by running the following command in the SO-ub container as root:
<pre>
forever list
</pre>
* You should see a status similar to following with an uptime:
<pre>
info: Forever processes running
data: uid command script forever pid id logfile uptime
data: [0] uivz /usr/bin/nodejs skyquake.js --enable-https --keyfile-path=/usr/rift/etc/ssl/current.key --certfile-path=/usr/rift/etc/ssl/current.cert 21071 21082 /root/.forever/forever.log 0:18:12:3.231
</pre>
* In case the UI server process has issues, you won't see an uptime but will instead see a status "STOPPED" in that position.
* In case the UI server process never started, you'll see a status saying "No forever processes running".

===Restarting UI===
* The UI is restarted when the SO module (launchpad) is restarted.
* However, in case just the UI needs to be restarted, you can run the following command in the SO-ub container as root:
<pre>
forever restartall
</pre>

===Known error messages in the UI and their solution===

==Troubleshooting SO==

===SO status===
The SO now starts as a service, but earlier versions of the SO used to run SO as a process.
To check if the SO is running as a service, run the following command:
<pre>
lxc exec SO-ub systemctl status launchpad.service
</pre>

===Restarting SO===
Note: Restarting the SO also restarts the UI.

When the SO has been started as a service (see SO status section above), use the following commands to restart the SO:
<pre>
lxc exec SO-ub systemctl stop launchpad.service
lxc exec SO-ub systemctl start launchpad.service
</pre>

When SO hasn't been started as a service, please follow the following instructions to restart the SO
lxc restart SO-ub # Optional, Needed if there is an existing running instance of launchpad
lxc exec SO-ub -- nohup sudo -b -H /usr/rift/rift-shell -r -i /usr/rift -a /usr/rift/.artifacts -- ./demos/launchpad.py --use-xml-mode

===Known error messages in the SO and their solution===

==Troubleshooting RO==

===RO status===
The status of the RO process can be checked by running the following command in the RO container as root:
<pre>
service osm-ro status
● osm-ro.service - openmano server
Loaded: loaded (/etc/systemd/system/osm-ro.service; disabled; vendor preset: enabled)
Active: active (running) since Wed 2017-04-02 16:50:21 UTC; 2s ago
Main PID: 550 (python)
Tasks: 1
Memory: 51.2M
CPU: 717ms
CGroup: /system.slice/osm-ro.service
└─550 python openmanod -c /etc/osm/openmanod.cfg --log-file=/var/log/osm/openmano.log

Nov 02 16:50:21 RO-integration systemd[1]: Started openmano server.
</pre>

In case it is not running, try to see the last logs at '''/var/log/osm/openmano.log'''

===Restarting RO===
RO can be restarted on the RO container at:
<pre>service osm-ro restart</pre>

===Known error messages in the RO and their solution===
Possible known errors are:

====Invalid openstack credentials====

SYMPTOM: At deployment it appears the error message: Not possible to get_networks_list from VIM: AuthorizationFailure: Authorization Failed: The resource could not be found. (HTTPS: 404)

CAUSE: Openstack is not properly added to openmano with the right credentials

SOLUTION:
* See the steps at [[OSM_Release_TWO#Openstack_site]]. If the problem persist ensure openstack is properly configured.
* Ensure you have access to the openstack endpoints: if port 5000 is redirected using iptables, other endpoint ports must also be redirected.
* Use "v2" authorization URL. "v3" is currently experimental in the master branch and is not recommended.
* If https (instead of http) is used for authorization URL, you can either use the insecure option at datacenter-create (See [[Openstack_configuration_(Release_TWO)#Add_openstack_at_OSM]]); or install the certificate at RO container, by e.g. putting a .crt (not .pem) certificate at /usr/local/share/ca-certificates and running update-ca-certificates.

Can be checked using openstack client with:
sudo apt install python-openstackclient
openstack --os-project-name <auth-project-name> --os-url <auth-url> --os-username <auth-username> --os-password <auth-password> --debug network list
openstack --os-project-name <auth-project-name> --os-url <auth-url> --os-username <auth-username> --os-password <auth-password> --debug host list
openstack --os-project-name <auth-project-name> --os-url <auth-url> --os-username <auth-username> --os-password <auth-password> --debug flavor list
openstack --os-project-name <auth-project-name> --os-url <auth-url> --os-username <auth-username> --os-password <auth-password> --debug server list
#providing the same URL, credentials as you provide to openmano. The (--debug) will show more info so that you will see the IP/ports it try to access

====Wrong database version====

SYMPTOM: osm-ro service fails. At openmano logs appear:
<pre>2016-11-02T17:19:51 CRITICAL openmano openmanod:268 DATABASE wrong version '0.15'. Try to upgrade/downgrade to version '0.16' with 'database_utils/migrate_mano_db.sh'</pre>

CAUSE: Openmano has been upgraded with a new version that requieres a new database version.

SOLUTION: To upgrade de database version run database_utils/migrate_mano_db.sh and provide credentials if needed (by default database user is 'mano', and database password is 'manopw')

==Troubleshooting VCA==

===VCA status===
<pre>lxc exec VCA -- juju status</pre>

Check that juju account is in 'green' status in the UI

<pre>lxc exec VCA -- juju config <app> </pre>
<pre>lxc exec VCA -- juju list-actions <app> </pre>
<pre>lxc exec VCA -- juju show-action-status </pre>
<pre>lxc exec VCA -- juju show-action-output <action-id> </pre>

===Restarting VCA===

===Known error messages in the VCA and their solution===

=Software upgrade (source code)=
OSM is being upgraded periodically to fix bugs that are being reported. Last version corresponds with the tag v1.0.5. These guidelines show you how to upgrade the different components.

==UI upgrade source code==

'''Note:''' It is recommended to upgrade both SO and UI modules together.

Execute at UI container ("lxc exec SO-ub bash" to enter into the container, "exit" to exit)

cd /root/UI
git pull --rebase
git checkout tags/v2.0.1
make clean && make -j16 && make install

Follow [[Logs_and_troubleshooting_(Release_TWO)#Software_upgrade#SO_upgrade|SO upgrade]] to upgrade SO and restart launchpad.

==SO upgrade source code==

Execute at SO container ("lxc exec SO-ub bash" to enter into the container, "exit" to exit)

cd /root/SO
git pull --rebase
git checkout tags/v2.0.1
make clean # Clean the previous installation
./BUILD.sh # Install the new version

Exit from SO-container and restart SO-ub container and Launchpad

lxc restart SO-ub
# lxc exec SO-ub -- nohup sudo -b -H /usr/rift/rift-shell -r -i /usr/rift -a /usr/rift/.artifacts -- ./demos/launchpad.py --use-xml-mode

==RO upgrade source code==

Execute at RO container ("lxc exec RO bash" to enter into the container, "exit" to exit)

service osm-ro stop
#git -C /opt/openmano stash #required if the original config file has changed
git -C /opt/openmano pull --rebase
git -C /opt/openmano checkout tags/v2.0.1
#git -C /opt/openmano stash pop #required if the original file has changed
/opt/openmano/database_utils/migrate_mano_db.sh
service osm-ro start

=Software upgrade (binaries)=

Under elaboration

Logs and troubleshooting (Release TWO)

2017-04-28T20:35:48Z

Chamarty: Add juju debug commands

__TOC__

=Logs=
==UI logs==

The server-side UI logs can be obtained on the SO-ub container at:
<pre>
/usr/rift/usr/share/rw.ui/skyquake/err.log
/usr/rift/usr/share/rw.ui/skyquake/out.log
</pre>

Client side UI logs can be obtained in the Developer Console in a browser.

==SO logs==

SO logs can be obtained on the SO-ub container at:
<pre>
/var/log/rift/rift.log
</pre>

==RO logs==
RO logs can be obtained on the RO container at:
<pre>/var/log/osm/openmano.log</pre>

Log file and log level (''debug'' by default) can be set at file:
<pre>/etc/osm/openmanod.cfg</pre>

==VCA logs==

=Troubleshooting=

==Troubleshooting UI==

===UI status===
* The status of the UI process can be checked by running the following command in the SO-ub container as root:
<pre>
forever list
</pre>
* You should see a status similar to following with an uptime:
<pre>
info: Forever processes running
data: uid command script forever pid id logfile uptime
data: [0] uivz /usr/bin/nodejs skyquake.js --enable-https --keyfile-path=/usr/rift/etc/ssl/current.key --certfile-path=/usr/rift/etc/ssl/current.cert 21071 21082 /root/.forever/forever.log 0:18:12:3.231
</pre>
* In case the UI server process has issues, you won't see an uptime but will instead see a status "STOPPED" in that position.
* In case the UI server process never started, you'll see a status saying "No forever processes running".

===Restarting UI===
* The UI is restarted when the SO module (launchpad) is restarted.
* However, in case just the UI needs to be restarted, you can run the following command in the SO-ub container as root:
<pre>
forever restartall
</pre>

===Known error messages in the UI and their solution===

==Troubleshooting SO==

===SO status===
The SO now starts as a service, but earlier versions of the SO used to run SO as a process.
To check if the SO is running as a service, run the following command:
<pre>
lxc exec SO-ub systemctl status launchpad.service
</pre>

===Restarting SO===
Note: Restarting the SO also restarts the UI.

When the SO has been started as a service (see SO status section above), use the following commands to restart the SO:
<pre>
lxc exec SO-ub systemctl stop launchpad.service
lxc exec SO-ub systemctl start launchpad.service
</pre>

When SO hasn't been started as a service, please follow the following instructions to restart the SO
lxc restart SO-ub # Optional, Needed if there is an existing running instance of launchpad
lxc exec SO-ub -- nohup sudo -b -H /usr/rift/rift-shell -r -i /usr/rift -a /usr/rift/.artifacts -- ./demos/launchpad.py --use-xml-mode

===Known error messages in the SO and their solution===

==Troubleshooting RO==

===RO status===
The status of the RO process can be checked by running the following command in the RO container as root:
<pre>
service osm-ro status
● osm-ro.service - openmano server
Loaded: loaded (/etc/systemd/system/osm-ro.service; disabled; vendor preset: enabled)
Active: active (running) since Wed 2017-04-02 16:50:21 UTC; 2s ago
Main PID: 550 (python)
Tasks: 1
Memory: 51.2M
CPU: 717ms
CGroup: /system.slice/osm-ro.service
└─550 python openmanod -c /etc/osm/openmanod.cfg --log-file=/var/log/osm/openmano.log

Nov 02 16:50:21 RO-integration systemd[1]: Started openmano server.
</pre>

In case it is not running, try to see the last logs at '''/var/log/osm/openmano.log'''

===Restarting RO===
RO can be restarted on the RO container at:
<pre>service osm-ro restart</pre>

===Known error messages in the RO and their solution===
Possible known errors are:

====Invalid openstack credentials====

SYMPTOM: At deployment it appears the error message: Not possible to get_networks_list from VIM: AuthorizationFailure: Authorization Failed: The resource could not be found. (HTTPS: 404)

CAUSE: Openstack is not properly added to openmano with the right credentials

SOLUTION:
* See the steps at [[OSM_Release_TWO#Openstack_site]]. If the problem persist ensure openstack is properly configured.
* Ensure you have access to the openstack endpoints: if port 5000 is redirected using iptables, other endpoint ports must also be redirected.
* Use "v2" authorization URL. "v3" is currently experimental in the master branch and is not recommended.
* If https (instead of http) is used for authorization URL, you can either use the insecure option at datacenter-create (See [[Openstack_configuration_(Release_TWO)#Add_openstack_at_OSM]]); or install the certificate at RO container, by e.g. putting a .crt (not .pem) certificate at /usr/local/share/ca-certificates and running update-ca-certificates.

Can be checked using openstack client with:
sudo apt install python-openstackclient
openstack --os-project-name <auth-project-name> --os-url <auth-url> --os-username <auth-username> --os-password <auth-password> --debug network list
openstack --os-project-name <auth-project-name> --os-url <auth-url> --os-username <auth-username> --os-password <auth-password> --debug host list
openstack --os-project-name <auth-project-name> --os-url <auth-url> --os-username <auth-username> --os-password <auth-password> --debug flavor list
openstack --os-project-name <auth-project-name> --os-url <auth-url> --os-username <auth-username> --os-password <auth-password> --debug server list
#providing the same URL, credentials as you provide to openmano. The (--debug) will show more info so that you will see the IP/ports it try to access

====Wrong database version====

SYMPTOM: osm-ro service fails. At openmano logs appear:
<pre>2016-11-02T17:19:51 CRITICAL openmano openmanod:268 DATABASE wrong version '0.15'. Try to upgrade/downgrade to version '0.16' with 'database_utils/migrate_mano_db.sh'</pre>

CAUSE: Openmano has been upgraded with a new version that requieres a new database version.

SOLUTION: To upgrade de database version run database_utils/migrate_mano_db.sh and provide credentials if needed (by default database user is 'mano', and database password is 'manopw')

==Troubleshooting VCA==

===VCA status===
<pre>lxc exec VCA -- juju status</pre>

Check that juju account is in 'green' status in the UI

<pre>lxc exec VCA -- juju config <app> </pre>
<pre>lxc exec VCA -- juju list-actions <app> </pre>
<pre>lxc exec VCA -- juju show-action-status </pre>
<pre>lxc exec VCA -- juju show-action-output <action-id> </pre>

Check that juju account is in 'green' status in the UI
===Restarting VCA===

===Known error messages in the VCA and their solution===

=Software upgrade (source code)=
OSM is being upgraded periodically to fix bugs that are being reported. Last version corresponds with the tag v1.0.5. These guidelines show you how to upgrade the different components.

==UI upgrade source code==

'''Note:''' It is recommended to upgrade both SO and UI modules together.

Execute at UI container ("lxc exec SO-ub bash" to enter into the container, "exit" to exit)

cd /root/UI
git pull --rebase
git checkout tags/v2.0.1
make clean && make -j16 && make install

Follow [[Logs_and_troubleshooting_(Release_TWO)#Software_upgrade#SO_upgrade|SO upgrade]] to upgrade SO and restart launchpad.

==SO upgrade source code==

Execute at SO container ("lxc exec SO-ub bash" to enter into the container, "exit" to exit)

cd /root/SO
git pull --rebase
git checkout tags/v2.0.1
make clean # Clean the previous installation
./BUILD.sh # Install the new version

Exit from SO-container and restart SO-ub container and Launchpad

lxc restart SO-ub
# lxc exec SO-ub -- nohup sudo -b -H /usr/rift/rift-shell -r -i /usr/rift -a /usr/rift/.artifacts -- ./demos/launchpad.py --use-xml-mode

==RO upgrade source code==

Execute at RO container ("lxc exec RO bash" to enter into the container, "exit" to exit)

service osm-ro stop
#git -C /opt/openmano stash #required if the original config file has changed
git -C /opt/openmano pull --rebase
git -C /opt/openmano checkout tags/v2.0.1
#git -C /opt/openmano stash pop #required if the original file has changed
/opt/openmano/database_utils/migrate_mano_db.sh
service osm-ro start

=Software upgrade (binaries)=

Under elaboration

Reference VNF and NS Descriptors (Release ONE)

2017-03-08T19:39:39Z

Chamarty: Instructions to create OSM packages

The following reference examples are provided to help VNF vendors to create their own descriptors (NSD, VNFD) usable in OSM. Please follow the below instruction to create descriptor packages

* Clone the descriptor-packages repo:
git clone https://osm.etsi.org/gerrit/osm/descriptor-packages
* Create a new VNF folder under src/vnfd and copy the VNF yaml descriptors in the new folder
* Create a new NS folder under src/nsd and copy the NS yaml descriptors in the new folder
* Build VNF and NS packages
make
* Packages will be created under build/vnfd_pkgs and build/nsd_pkgs

= Reference NS#1: Testing an endpoint VNF =

The following network service captures a simple test setup where a VNF is tested with a traffic generator VNF (or a simple VNF/VM with a basic client application). For simplicity, this network service assumes that the VNF under test is the endpoint of a given service (e.g. DNS, AAA, etc.) and does not require special conditions or resource allocation besides the usual in a standard cloud environments.

[[File:example_ns_1.png | 450px | right | Reference NS #1: Testing an endpoint VNF]]

In this example, unless otherwise specified in the description, the following defaults apply:
* CPs are regular para-virtualized interfaces (VirtIO or equivalent).
* VLs provide E-LAN connectivity via regular (overlay) networks provided by the VIM.
* VLs provide IP addressing via DHCP if applicable.
* Mapping between internal and external CPs may be either direct (as aliases) or via an intermediate VL.
* VIM+NFVI can guarantee predictable ordering of guest interfaces' virtual PCI addresses.

In the case of REF_NS_1:
* When deploying the NS, VL1 would be typically mapped to a pre-created VIM network intended to provide management IP address to VNFs via DHCP.
* DHCP in VL2 may be optional.

== Reference VNF#11: Endpoint VNF ==
[[File:ref_vnf_11.png | 350px | right | Reference VNF#11: Endpoint]]

=== Description in common language ===
* '''Name:''' Ref_VNF_11
** '''Component:''' Ref_VM1
*** '''Memory:''' 2 GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 8 GB
*** '''Image:''' ref_vm1.qcow2
** '''Component:''' Ref_VM2
*** '''Memory:''' 4GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 16GB
*** '''Image:''' ref_vm2.qcow2
** '''Internal Virtual Link:''' VL12
*** No DHCP server is enabled.
*** Static addressing may be used at CP iface11 and CP iface21.

=== OSM VNF descriptor for VNF#11 ===
[https://osm.etsi.org/gitweb/?p=osm/descriptor-packages.git;a=blob;f=src/vnfd/ref11_vnf/ref11_vnfd.yaml;h=f308282b4f3fab25161e780c084efd82bc0f42d2;hb=HEAD VNF11.yaml]

== Reference VNF#21: Generator 1 port ==
[[File:ref_vnf_21.png | 350px | right | Reference VNF#21: Generator 1 port]]

=== Description in common language ===
* '''Name:''' Ref_VNF_21
** '''Component:''' Ref_VM5
*** '''Memory:''' 1 GB
*** '''CPU:''' 1 vCPU
*** '''Storage:''' 16 GB
*** '''Image:''' ref_vm21.qcow2

=== OSM VNF descriptor for VNF#21 ===
[https://osm.etsi.org/gitweb/?p=osm/descriptor-packages.git;a=blob;f=src/vnfd/ref21_vnf/ref21_vnfd.yaml;h=f308282b4f3fab25161e780c084efd82bc0f42d2;hb=HEAD VNF21.yaml]

== OSM NS descriptor for NS#1 ==
[https://osm.etsi.org/gitweb/?p=osm/descriptor-packages.git;a=blob;f=src/vnfd/ref1_ns/ref1_nsd.yaml;h=f308282b4f3fab25161e780c084efd82bc0f42d2;hb=HEAD NS1.yaml]

= Reference NS #2: Testing a middle point VNF =
[[File:example_ns_2.png | 400px | right | Reference NS #2: Testing a middle point VNF]]

The following network service captures a more advanced test setup where the VNF under test is a middlepoint in the communication (e.g. router, EPC) and might require special conditions or resource allocation and connectivity foreseen in NFV ISG specs. In this case, the traffic generator VNF behaves as source and sink of traffic and might also require special resource allocation.

In this example, unless otherwise specified in the description, the following applies:
* Same defaults as in NS#1
* vCPUs must be pinned to dedicated physical CPUs, with no over subscription.
* CPUs, memory and interfaces (if applicable) to be assigned to a given VM should belong to the same socket (NUMA awareness).
* Memory assigned to VMs should be backed by host's huge pages memory.
* VL2 and VL3 are E-Line underlay connectivity. No DHCP is required.

== Reference VNF#12: Middle point VNF ==
[[File:ref_vnf_12.png | 400px | right | Reference VNF#12: Middle point]]

=== Description in common language ===
* '''Name:''' Ref_VNF_12
** '''Component:''' Ref_VM3
*** '''Memory:''' 2 GB huge pages
*** '''CPU:''' 2 vCPU (= CPU)
*** '''Storage:''' 8 GB
*** '''Image:''' ref_vm3.qcow2
** '''Component:''' Ref_VM4
*** '''Memory:''' 4GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 16GB
*** '''Image:''' ref_vm4.qcow2
** '''Connection Point:''' iface42 (west)
*** '''Type:''' Passthrough
** '''Connection Point:''' iface43 (east)
*** '''Type:''' SR-IOV

=== OSM VNF descriptor for VNF#12 ===
[https://osm.etsi.org/gitweb/?p=osm/descriptor-packages.git;a=blob;f=src/vnfd/ref12_vnf/ref12_vnfd.yaml;h=f308282b4f3fab25161e780c084efd82bc0f42d2;hb=HEAD VNF12.yaml]

== Reference VNF#22: Generator 2 ports ==

[[File:ref_vnf_22.png | 400px | right | Reference VNF#22: Generator 2 ports]]

=== Description in common language ===
* '''Name:''' Ref_VNF_22
** '''Component:''' Ref_VM6
*** '''Memory:''' 1 GB huge pages
*** '''CPU:''' 1 vCPU (= CPU)
*** '''Storage:''' 16 GB
*** '''Image:''' ref_vm22.qcow2
** '''Connection Point:''' iface61 (west)
*** '''Type:''' Passthrough
** '''Connection Point:''' iface62 (east)
*** '''Type:''' SR-IOV

=== OSM VNF descriptor for VNF#22 ===
[https://osm.etsi.org/gitweb/?p=osm/descriptor-packages.git;a=blob;f=src/vnfd/ref22_vnf/ref22_vnfd.yaml;h=f308282b4f3fab25161e780c084efd82bc0f42d2;hb=HEAD VNF22.yaml]

== OSM NS descriptor for NS#2 ==
[https://osm.etsi.org/gitweb/?p=osm/descriptor-packages.git;a=blob;f=src/vnfd/ref2_ns/ref2_nsd.yaml;h=f308282b4f3fab25161e780c084efd82bc0f42d2;hb=HEAD NS2.yaml]

Reference VNF and NS Descriptors (Release ONE)

2017-03-08T19:30:14Z

Chamarty: Add links to OSM reference descriptors

Reference VNF and NS Descriptors (Release ONE)

2017-03-01T16:28:37Z

Chamarty: Updated descriptors for scenario 2

The following reference examples are provided to help VNF vendors to create their own descriptors (NSD, VNFD) usable in OSM.

= Reference NS#1: Testing an endpoint VNF =

The following network service captures a simple test setup where a VNF is tested with a traffic generator VNF (or a simple VNF/VM with a basic client application). For simplicity, this network service assumes that the VNF under test is the endpoint of a given service (e.g. DNS, AAA, etc.) and does not require special conditions or resource allocation besides the usual in a standard cloud environments.

[[File:example_ns_1.png | 450px | right | Reference NS #1: Testing an endpoint VNF]]

In this example, unless otherwise specified in the description, the following defaults apply:
* CPs are regular para-virtualized interfaces (VirtIO or equivalent).
* VLs provide E-LAN connectivity via regular (overlay) networks provided by the VIM.
* VLs provide IP addressing via DHCP if applicable.
* Mapping between internal and external CPs may be either direct (as aliases) or via an intermediate VL.
* VIM+NFVI can guarantee predictable ordering of guest interfaces' virtual PCI addresses.

In the case of REF_NS_1:
* When deploying the NS, VL1 would be typically mapped to a pre-created VIM network intended to provide management IP address to VNFs via DHCP.
* DHCP in VL2 may be optional.

== Reference VNF#11: Endpoint VNF ==
[[File:ref_vnf_11.png | 350px | right | Reference VNF#11: Endpoint]]

=== Description in common language ===
* '''Name:''' Ref_VNF_11
** '''Component:''' Ref_VM1
*** '''Memory:''' 2 GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 8 GB
*** '''Image:''' ref_vm1.qcow2
** '''Component:''' Ref_VM2
*** '''Memory:''' 4GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 16GB
*** '''Image:''' ref_vm2.qcow2
** '''Internal Virtual Link:''' VL12
*** No DHCP server is enabled.
*** Static addressing may be used at CP iface11 and CP iface21.

=== OSM VNF descriptor for VNF#11 ===
[[File:Ref_VNF_11.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:
- connection-point:
- name: mgmt0
type: VPORT
description: A simple VNF descriptor w/ VM1 and VM2
id: 287671e2-2858-48cf-a13c-b4cb1351aa9f
name: Ref_VNF_11
short-name: Ref_VNF_11
vdu:
- external-interface:
- name: iface10
virtual-interface:
type: OM-MGMT
vnfd-connection-point-ref: mgmt0
id: abd6831e-f811-4580-9aad-1de9c6424180
image: ref_vm1.qcow2
name: Ref_VM1
vm-flavor:
memory-mb: '2048'
storage-gb: '8'
vcpu-count: '2'
vendor: ETSI
version: '1.0'
</nowiki>

== Reference VNF#21: Generator 1 port ==
[[File:ref_vnf_21.png | 350px | right | Reference VNF#21: Generator 1 port]]

=== Description in common language ===
* '''Name:''' Ref_VNF_21
** '''Component:''' Ref_VM5
*** '''Memory:''' 1 GB
*** '''CPU:''' 1 vCPU
*** '''Storage:''' 16 GB
*** '''Image:''' ref_vm21.qcow2

=== OSM VNF descriptor for VNF#21 ===
[[File:Ref_VNF_21.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:
- connection-point:
- name: cp1
type: VPORT
description: A simple VNF descriptor w/ one VDU
id: d6c25720-895a-40a2-b303-b2a98d10674c
name: Ref_Vnf_21
short-name: Ref_Vnf_21
vdu:
- external-interface:
- name: eth0
virtual-interface:
type: VIRTIO
vnfd-connection-point-ref: cp1
id: abd6831e-f811-4580-9aad-1de9c6424180
image: ref_vm21.qcow2
name: Ref_VM5
vm-flavor:
memory-mb: '1024'
storage-gb: '16'
vcpu-count: '1'
vendor: ETSI
version: '1.0'
</nowiki>

== OSM NS descriptor for NS#1 ==
[[File:Ref_NS1.tar.gz]]

<nowiki>
nsd:nsd-catalog:
nsd:
- constituent-vnfd:
- member-vnf-index: '1'
start-by-default: 'true'
vnfd-id-ref: d6c25720-895a-40a2-b303-b2a98d10674c
- member-vnf-index: '2'
vnfd-id-ref: 287671e2-2858-48cf-a13c-b4cb1351aa9f
description: Reference NS 1
id: 9b684262-ded5-4d43-82d3-5e2bf69b7446
name: Ref_NS_1
vendor: ETSI
vld:
- description: Mgmt VL
id: 54c04
name: VL1
short-name: VL1
type: ELAN
vendor: ETSI
vnfd-connection-point-ref:
- member-vnf-index-ref: '1'
vnfd-connection-point-ref: mgmt
vnfd-id-ref: d6c25720-895a-40a2-b303-b2a98d10674c
- member-vnf-index-ref: '2'
vnfd-connection-point-ref: mgmt0
vnfd-id-ref: 287671e2-2858-48cf-a13c-b4cb1351aa9f
</nowiki>

= Reference NS #2: Testing a middle point VNF =
[[File:example_ns_2.png | 400px | right | Reference NS #2: Testing a middle point VNF]]

The following network service captures a more advanced test setup where the VNF under test is a middlepoint in the communication (e.g. router, EPC) and might require special conditions or resource allocation and connectivity foreseen in NFV ISG specs. In this case, the traffic generator VNF behaves as source and sink of traffic and might also require special resource allocation.

In this example, unless otherwise specified in the description, the following applies:
* Same defaults as in NS#1
* vCPUs must be pinned to dedicated physical CPUs, with no over subscription.
* CPUs, memory and interfaces (if applicable) to be assigned to a given VM should belong to the same socket (NUMA awareness).
* Memory assigned to VMs should be backed by host's huge pages memory.
* VL2 and VL3 are E-Line underlay connectivity. No DHCP is required.

== Reference VNF#12: Middle point VNF ==
[[File:ref_vnf_12.png | 400px | right | Reference VNF#12: Middle point]]

=== Description in common language ===
* '''Name:''' Ref_VNF_12
** '''Component:''' Ref_VM3
*** '''Memory:''' 2 GB huge pages
*** '''CPU:''' 2 vCPU (= CPU)
*** '''Storage:''' 8 GB
*** '''Image:''' ref_vm3.qcow2
** '''Component:''' Ref_VM4
*** '''Memory:''' 4GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 16GB
*** '''Image:''' ref_vm4.qcow2
** '''Connection Point:''' iface42 (west)
*** '''Type:''' Passthrough
** '''Connection Point:''' iface43 (east)
*** '''Type:''' SR-IOV

=== OSM VNF descriptor for VNF#12 ===
[[File:Ref_VNF_12.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:
- connection-point:
- name: mgmt0
type: VPORT
description: A simple VNF descriptor w/ two VDU
id: abae3d33-36ec-4707-95aa-e48907bf2442
name: Ref_Vnf_12
short-name: Ref_Vnf_12
vdu:
- description: Middlepoint
external-interface:
- name: iface30
virtual-interface:
type: OM-MGMT
vnfd-connection-point-ref: mgmt0
guest-epa:
cpu-pinning-policy: DEDICATED
id: abd6831e-f811-4580-9aad-1de9c6424180
image: ref_vm3.qcow2
internal-connection-point:
- id: 5f813
name: icp0
type: VPORT
internal-interface:
- name: iface31
vdu-internal-connection-point-ref: 5f813
virtual-interface:
type: VIRTIO
name: Ref_VM3
vm-flavor:
memory-mb: '2048'
storage-gb: '8'
vcpu-count: '2'
- external-interface:
- name: iface42
virtual-interface:
type: PCI-PASSTHROUGH
- name: iface43
virtual-interface:
type: SR-IOV
guest-epa:
cpu-pinning-policy: DEDICATED
id: e526e
internal-connection-point:
- id: 9ec35
name: icp0
type: VPORT
internal-interface:
- name: iface41
vdu-internal-connection-point-ref: 9ec35
virtual-interface:
type: VIRTIO
vendor: ETSI
version: '1.0'
</nowiki>

== Reference VNF#22: Generator 2 ports ==

[[File:ref_vnf_22.png | 400px | right | Reference VNF#22: Generator 2 ports]]

=== Description in common language ===
* '''Name:''' Ref_VNF_22
** '''Component:''' Ref_VM6
*** '''Memory:''' 1 GB huge pages
*** '''CPU:''' 1 vCPU (= CPU)
*** '''Storage:''' 16 GB
*** '''Image:''' ref_vm22.qcow2
** '''Connection Point:''' iface61 (west)
*** '''Type:''' Passthrough
** '''Connection Point:''' iface62 (east)
*** '''Type:''' SR-IOV

=== OSM VNF descriptor for VNF#22 ===
[[File:Ref_VNF_22.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:
- connection-point:
- name: cp1
type: VPORT
description: A simple VNF descriptor w/ one VDU
id: c993c90e-857f-499e-aad3-74f1667216d2
name: Ref_VNF_22
short-name: Ref_VNF_22
vdu:
- external-interface:
- name: eth0
virtual-interface:
type: VIRTIO
vnfd-connection-point-ref: cp1
- name: iface61
virtual-interface:
type: PCI-PASSTHROUGH
- name: iface62
virtual-interface:
type: SR-IOV
id: abd6831e-f811-4580-9aad-1de9c6424180
image: ref_vm22.qcow2
name: Ref_VM6
vm-flavor:
memory-mb: '1024'
storage-gb: '16'
vcpu-count: '1'
vendor: ETSI
version: '1.0'
</nowiki>

== OSM NS descriptor for NS#2 ==
[[File:Ref_NS_2.tar.gz]]
<nowiki>
nsd:nsd-catalog:
nsd:
- constituent-vnfd:
- member-vnf-index: '1'
vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- member-vnf-index: '2'
vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
description: Reference NS2
id: cbd6d406-57ff-40ee-8155-8013a40f6bad
name: Ref_NS_2
vendor: ETSI
vld:
- id: '97465'
name: Mgmt
vnfd-connection-point-ref:
- member-vnf-index-ref: '1'
vnfd-connection-point-ref: mgmt0
vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- member-vnf-index-ref: '2'
vnfd-connection-point-ref: mgmt
vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
- id: f66e6
vnfd-connection-point-ref:
- member-vnf-index-ref: '1'
vnfd-connection-point-ref: east
vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- member-vnf-index-ref: '2'
vnfd-connection-point-ref: east
vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
</nowiki>

Reference VNF and NS Descriptors (Release ONE)

2017-03-01T16:21:50Z

Chamarty: Updated descriptors for scenario 1

The following reference examples are provided to help VNF vendors to create their own descriptors (NSD, VNFD) usable in OSM.

= Reference NS#1: Testing an endpoint VNF =

The following network service captures a simple test setup where a VNF is tested with a traffic generator VNF (or a simple VNF/VM with a basic client application). For simplicity, this network service assumes that the VNF under test is the endpoint of a given service (e.g. DNS, AAA, etc.) and does not require special conditions or resource allocation besides the usual in a standard cloud environments.

[[File:example_ns_1.png | 450px | right | Reference NS #1: Testing an endpoint VNF]]

In this example, unless otherwise specified in the description, the following defaults apply:
* CPs are regular para-virtualized interfaces (VirtIO or equivalent).
* VLs provide E-LAN connectivity via regular (overlay) networks provided by the VIM.
* VLs provide IP addressing via DHCP if applicable.
* Mapping between internal and external CPs may be either direct (as aliases) or via an intermediate VL.
* VIM+NFVI can guarantee predictable ordering of guest interfaces' virtual PCI addresses.

In the case of REF_NS_1:
* When deploying the NS, VL1 would be typically mapped to a pre-created VIM network intended to provide management IP address to VNFs via DHCP.
* DHCP in VL2 may be optional.

== Reference VNF#11: Endpoint VNF ==
[[File:ref_vnf_11.png | 350px | right | Reference VNF#11: Endpoint]]

=== Description in common language ===
* '''Name:''' Ref_VNF_11
** '''Component:''' Ref_VM1
*** '''Memory:''' 2 GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 8 GB
*** '''Image:''' ref_vm1.qcow2
** '''Component:''' Ref_VM2
*** '''Memory:''' 4GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 16GB
*** '''Image:''' ref_vm2.qcow2
** '''Internal Virtual Link:''' VL12
*** No DHCP server is enabled.
*** Static addressing may be used at CP iface11 and CP iface21.

=== OSM VNF descriptor for VNF#11 ===
[[File:Ref_VNF_11.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:
- connection-point:
- name: mgmt0
type: VPORT
description: A simple VNF descriptor w/ VM1 and VM2
id: 287671e2-2858-48cf-a13c-b4cb1351aa9f
name: Ref_VNF_11
short-name: Ref_VNF_11
vdu:
- external-interface:
- name: iface10
virtual-interface:
type: OM-MGMT
vnfd-connection-point-ref: mgmt0
id: abd6831e-f811-4580-9aad-1de9c6424180
image: ref_vm1.qcow2
name: Ref_VM1
vm-flavor:
memory-mb: '2048'
storage-gb: '8'
vcpu-count: '2'
vendor: ETSI
version: '1.0'
</nowiki>

== Reference VNF#21: Generator 1 port ==
[[File:ref_vnf_21.png | 350px | right | Reference VNF#21: Generator 1 port]]

=== Description in common language ===
* '''Name:''' Ref_VNF_21
** '''Component:''' Ref_VM5
*** '''Memory:''' 1 GB
*** '''CPU:''' 1 vCPU
*** '''Storage:''' 16 GB
*** '''Image:''' ref_vm21.qcow2

=== OSM VNF descriptor for VNF#21 ===
[[File:Ref_VNF_21.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:
- connection-point:
- name: cp1
type: VPORT
description: A simple VNF descriptor w/ one VDU
id: d6c25720-895a-40a2-b303-b2a98d10674c
name: Ref_Vnf_21
short-name: Ref_Vnf_21
vdu:
- external-interface:
- name: eth0
virtual-interface:
type: VIRTIO
vnfd-connection-point-ref: cp1
id: abd6831e-f811-4580-9aad-1de9c6424180
image: ref_vm21.qcow2
name: Ref_VM5
vm-flavor:
memory-mb: '1024'
storage-gb: '16'
vcpu-count: '1'
vendor: ETSI
version: '1.0'
</nowiki>

== OSM NS descriptor for NS#1 ==
[[File:Ref_NS1.tar.gz]]

<nowiki>
nsd:nsd-catalog:
nsd:
- constituent-vnfd:
- member-vnf-index: '1'
start-by-default: 'true'
vnfd-id-ref: d6c25720-895a-40a2-b303-b2a98d10674c
- member-vnf-index: '2'
vnfd-id-ref: 287671e2-2858-48cf-a13c-b4cb1351aa9f
description: Reference NS 1
id: 9b684262-ded5-4d43-82d3-5e2bf69b7446
name: Ref_NS_1
vendor: ETSI
vld:
- description: Mgmt VL
id: 54c04
name: VL1
short-name: VL1
type: ELAN
vendor: ETSI
vnfd-connection-point-ref:
- member-vnf-index-ref: '1'
vnfd-connection-point-ref: mgmt
vnfd-id-ref: d6c25720-895a-40a2-b303-b2a98d10674c
- member-vnf-index-ref: '2'
vnfd-connection-point-ref: mgmt0
vnfd-id-ref: 287671e2-2858-48cf-a13c-b4cb1351aa9f
</nowiki>

= Reference NS #2: Testing a middle point VNF =
[[File:example_ns_2.png | 400px | right | Reference NS #2: Testing a middle point VNF]]

The following network service captures a more advanced test setup where the VNF under test is a middlepoint in the communication (e.g. router, EPC) and might require special conditions or resource allocation and connectivity foreseen in NFV ISG specs. In this case, the traffic generator VNF behaves as source and sink of traffic and might also require special resource allocation.

In this example, unless otherwise specified in the description, the following applies:
* Same defaults as in NS#1
* vCPUs must be pinned to dedicated physical CPUs, with no over subscription.
* CPUs, memory and interfaces (if applicable) to be assigned to a given VM should belong to the same socket (NUMA awareness).
* Memory assigned to VMs should be backed by host's huge pages memory.
* VL2 and VL3 are E-Line underlay connectivity. No DHCP is required.

== Reference VNF#12: Middle point VNF ==
[[File:ref_vnf_12.png | 400px | right | Reference VNF#12: Middle point]]

=== Description in common language ===
* '''Name:''' Ref_VNF_12
** '''Component:''' Ref_VM3
*** '''Memory:''' 2 GB huge pages
*** '''CPU:''' 2 vCPU (= CPU)
*** '''Storage:''' 8 GB
*** '''Image:''' ref_vm3.qcow2
** '''Component:''' Ref_VM4
*** '''Memory:''' 4GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 16GB
*** '''Image:''' ref_vm4.qcow2
** '''Connection Point:''' iface42 (west)
*** '''Type:''' Passthrough
** '''Connection Point:''' iface43 (east)
*** '''Type:''' SR-IOV

=== OSM VNF descriptor for VNF#12 ===
[[File:Ref_VNF_12.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: mgmt0
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ two VDU
vnfd:id: abae3d33-36ec-4707-95aa-e48907bf2442
vnfd:name: Ref_Vnf_12
vnfd:short-name: Ref_Vnf_12
vnfd:vdu:
- vnfd:description: Middlepoint
vnfd:external-interface:
- vnfd:name: iface30
vnfd:virtual-interface:
vnfd:type: OM-MGMT
vnfd:vnfd-connection-point-ref: mgmt0
vnfd:guest-epa:
vnfd:cpu-pinning-policy: DEDICATED
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm3.qcow2
vnfd:internal-connection-point:
- vnfd:id: 5f813
vnfd:name: icp0
vnfd:type: VPORT
vnfd:internal-interface:
- vnfd:name: iface31
vnfd:vdu-internal-connection-point-ref: 5f813
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:name: Ref_VM3
vnfd:vm-flavor:
vnfd:memory-mb: '2048'
vnfd:storage-gb: '8'
vnfd:vcpu-count: '2'
- vnfd:external-interface:
- vnfd:name: iface42
vnfd:virtual-interface:
vnfd:type: PCI-PASSTHROUGH
- vnfd:name: iface43
vnfd:virtual-interface:
vnfd:type: SR-IOV
vnfd:guest-epa:
vnfd:cpu-pinning-policy: DEDICATED
vnfd:id: e526e
vnfd:internal-connection-point:
- vnfd:id: 9ec35
vnfd:name: icp0
vnfd:type: VPORT
vnfd:internal-interface:
- vnfd:name: iface41
vnfd:vdu-internal-connection-point-ref: 9ec35
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:vendor: ETSI
vnfd:version: '1.0'
</nowiki>

== Reference VNF#22: Generator 2 ports ==

[[File:ref_vnf_22.png | 400px | right | Reference VNF#22: Generator 2 ports]]

=== Description in common language ===
* '''Name:''' Ref_VNF_22
** '''Component:''' Ref_VM6
*** '''Memory:''' 1 GB huge pages
*** '''CPU:''' 1 vCPU (= CPU)
*** '''Storage:''' 16 GB
*** '''Image:''' ref_vm22.qcow2
** '''Connection Point:''' iface61 (west)
*** '''Type:''' Passthrough
** '''Connection Point:''' iface62 (east)
*** '''Type:''' SR-IOV

=== OSM VNF descriptor for VNF#22 ===
[[File:Ref_VNF_22.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: cp1
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ one VDU
vnfd:id: c993c90e-857f-499e-aad3-74f1667216d2
vnfd:name: Ref_VNF_22
vnfd:short-name: Ref_VNF_22
vnfd:vdu:
- vnfd:external-interface:
- vnfd:name: eth0
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:vnfd-connection-point-ref: cp1
- vnfd:name: iface61
vnfd:virtual-interface:
vnfd:type: PCI-PASSTHROUGH
- vnfd:name: iface62
vnfd:virtual-interface:
vnfd:type: SR-IOV
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm22.qcow2
vnfd:name: Ref_VM6
vnfd:vm-flavor:
vnfd:memory-mb: '1024'
vnfd:storage-gb: '16'
vnfd:vcpu-count: '1'
vnfd:vendor: ETSI
vnfd:version: '1.0'
</nowiki>

== OSM NS descriptor for NS#2 ==
[[File:Ref_NS_2.tar.gz]]
<nowiki>
nsd:nsd-catalog:
nsd:nsd:
- nsd:constituent-vnfd:
- nsd:member-vnf-index: '1'
nsd:vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- nsd:member-vnf-index: '2'
nsd:vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
nsd:description: Reference NS2
nsd:id: cbd6d406-57ff-40ee-8155-8013a40f6bad
nsd:name: Ref_NS_2
nsd:vendor: ETSI
nsd:vld:
- nsd:id: '97465'
nsd:name: Mgmt
nsd:vnfd-connection-point-ref:
- nsd:member-vnf-index-ref: '1'
nsd:vnfd-connection-point-ref: mgmt0
nsd:vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- nsd:member-vnf-index-ref: '2'
nsd:vnfd-connection-point-ref: mgmt
nsd:vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
- nsd:id: f66e6
nsd:vnfd-connection-point-ref:
- nsd:member-vnf-index-ref: '1'
nsd:vnfd-connection-point-ref: east
nsd:vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- nsd:member-vnf-index-ref: '2'
nsd:vnfd-connection-point-ref: east
nsd:vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
</nowiki>

Logs and troubleshooting (Release ONE)

2017-01-19T13:26:36Z

Chamarty: VCA troubleshooting

'''Under elaboration'''

__TOC__

=Logs=
==UI logs==

The server-side UI logs can be obtained on the SO-ub container at:
<pre>
/usr/rift/usr/share/rw.ui/skyquake/err.log
/usr/rift/usr/share/rw.ui/skyquake/out.log
</pre>

Client side UI logs can be obtained in the Developer Console in a browser.

==SO logs==

SO logs can be obtained on the SO-ub container at:
<pre>
/var/log/rift/rift.log
</pre>

==RO logs==
RO logs can be obtained on the RO container at:
<pre>/var/log/openmano/openmano.log</pre>

Log file and log level (''debug'' by default) can be set at file:
<pre>/etc/default/openmanod.cfg</pre>

==VCA logs==

=Troubleshooting=

==Troubleshooting UI==

===UI status===
* The status of the UI process can be checked by running the following command in the SO-ub container as root:
<pre>
forever list
</pre>
* You should see a status similar to following with an uptime:
<pre>
info: Forever processes running
data: uid command script forever pid id logfile uptime
data: [0] uivz /usr/bin/nodejs skyquake.js --enable-https --keyfile-path=/usr/rift/etc/ssl/current.key --certfile-path=/usr/rift/etc/ssl/current.cert 21071 21082 /root/.forever/forever.log 0:18:12:3.231
</pre>
* In case the UI server process has issues, you won't see an uptime but will instead see a status "STOPPED" in that position.
* In case the UI server process never started, you'll see a status saying "No forever processes running".

===Restarting UI===
* The UI is restarted when the SO module (launchpad) is restarted.
* However, in case just the UI needs to be restarted, you can run the following command in the SO-ub container as root:
<pre>
forever restartall
</pre>

===Known error messages in the UI and their solution===

==Troubleshooting SO==

===SO status===
The SO now starts as a service, but earlier versions of the SO used to run SO as a process.
To check if the SO is running as a service, run the following command:
<pre>
lxc exec SO-ub systemctl status launchpad.service
</pre>

===Restarting SO===
Note: Restarting the SO also restarts the UI.

When the SO has been started as a service (see SO status section above), use the following commands to restart the SO:
<pre>
lxc exec SO-ub systemctl stop launchpad.service
lxc exec SO-ub systemctl start launchpad.service
</pre>

When SO hasn't been started as a service, please follow the following instructions to restart the SO
lxc restart SO-ub # Optional, Needed if there is an existing running instance of launchpad
lxc exec SO-ub -- nohup sudo -b -H /usr/rift/rift-shell -r -i /usr/rift -a /usr/rift/.artifacts -- ./demos/launchpad.py --use-xml-mode

===Known error messages in the SO and their solution===

==Troubleshooting RO==

===RO status===
The status of the RO process can be checked by running the following command in the RO container as root:
<pre>
service openmano status
● openmano.service - openmano server
Loaded: loaded (/etc/systemd/system/openmano.service; disabled; vendor preset: enabled)
Active: active (running) since Wed 2016-11-02 16:50:21 UTC; 2s ago
Main PID: 550 (python)
Tasks: 1
Memory: 51.2M
CPU: 717ms
CGroup: /system.slice/openmano.service
└─550 python /opt/openmano/openmanod.py -c /opt/openmano/openmanod.cfg --log-file=/opt/openmano/logs/openmano.log

Nov 02 16:50:21 RO-integration systemd[1]: Started openmano server.
</pre>

In case it is not running, try to see the last logs at '''/var/log/openmano/openmano.log'''

===Restarting RO===
RO can be restarted on the RO container at:
<pre>service openmano restart</pre>

===Known error messages in the RO and their solution===
Possible known errors are:

====Invalid openstack credentials====

SYMPTOM: At deployment it appears the error message: Not possible to get_networks_list from VIM: AuthorizationFailure: Authorization Failed: The resource could not be found. (HTTPS: 404)

CAUSE: Openstack is not properly added to openmano with the right credentials

SOLUTION:
* See the steps at [[OSM_Release_ONE#Openstack_site]]. If the problem persist ensure openstack is properly configured.
* Ensure you have access to the openstack endpoints: if port 5000 is redirected using iptables, other endpoint ports must also be redirected.
* use "v2" authorization URL. "v3" is on betta.
* if https (insetad of http) is used for authorization URL, ensure the certificate is installed at RO container, by e.g. putting a .crt (not .pem) certificate at /usr/local/share/ca-certificates and running update-ca-certificates.

Can be checked using openstack client with:
sudo apt install python-openstackclient
openstack --os-project-name <auth-project-name> --os-url <auth-url> --os-username <auth-username> --os-password <auth-password> --debug network list
openstack --os-project-name <auth-project-name> --os-url <auth-url> --os-username <auth-username> --os-password <auth-password> --debug host list
openstack --os-project-name <auth-project-name> --os-url <auth-url> --os-username <auth-username> --os-password <auth-password> --debug flavor list
openstack --os-project-name <auth-project-name> --os-url <auth-url> --os-username <auth-username> --os-password <auth-password> --debug server list
#providing the same URL, credentials as you provide to openmano. The (--debug) will show more info so that you will see the IP/ports it try to access

====Wrong database version====

SYMPTOM: openmano service fails. At openmano logs appear:
<pre>2016-11-02T17:19:51 CRITICAL openmano openmanod.py:268 DATABASE wrong version '0.15'. Try to upgrade/downgrade to version '0.16' with './database_utils/migrate_mano_db.sh'</pre>

CAUSE: Openmano has been upgraded with a new version that requieres a new database version.

SOLUTION: To upgrade de database version run ./database_utils/migrate_mano_db.sh and provide credentias if needed (by default database user is 'mano', and database password is 'manopw')

==Troubleshooting VCA==

===VCA status===
<pre>lxc VCA -- juju status</pre>

Check that juju account is in 'green' status in the UI

===Restarting VCA===

===Known error messages in the VCA and their solution===

=Software upgrade=
OSM is being upgraded periodically to fix bugs that are being reported. Last version corresponds with the tag v1.0.4. These guidelines show you how to upgrade the different components.

==UI upgrade==

'''Note:''' It is recommended to upgrade both SO and UI modules together.

Execute at UI container ("lxc exec SO-ub bash" to enter into the container, "exit" to exit)

cd /root/UI
git pull --rebase
git checkout tags/v1.0.4
make clean && make -j16 && make install

Follow [[Logs_and_troubleshooting_(Release_ONE)#Software_upgrade#SO_upgrade|SO upgrade]] to upgrade SO and restart launchpad.

==SO upgrade==

Execute at SO container ("lxc exec SO-ub bash" to enter into the container, "exit" to exit)

cd /root/SO
git checkout v1.0
git pull --rebase
git checkout tags/v1.0.4
make clean && make -j16 && make install

Exit from SO-container and restart SO-ub container and Launchpad

lxc restart SO-ub
lxc exec SO-ub -- nohup sudo -b -H /usr/rift/rift-shell -r -i /usr/rift -a /usr/rift/.artifacts -- ./demos/launchpad.py --use-xml-mode

==RO upgrade==

Execute at RO container ("lxc exec RO bash" to enter into the container, "exit" to exit)

service openmano stop
#git -C /opt/openmano stash #required if the original config file has changed
git -C /opt/openmano pull --rebase
git -C /opt/openmano checkout tags/v1.0.4
#git -C /opt/openmano stash pop #required if the original file has changed
/opt/openmano/database_utils/migrate_mano_db.sh
service openmano start

==VCA upgrade==

Creating your own VNF package (Release ONE)

2017-01-13T14:56:31Z

Chamarty: Add link to Charm creation

==VNF without primitives==
===Using web form===
You can access this web page and follow the instructions: http://riftio.com/osm-vnf-package-generator/

===Using the CLI tool===
*Clone the descriptor-packages repo:
git clone https://osm.etsi.org/gerrit/osm/descriptor-packages
*Run the following command to create a folder with all the files required for a single-VM VNF package:
./descriptor-packages/src/generate_descriptor_pkg.sh -t vnfd --image <IMAGE_PATH> -c <VNF_NAME>
*A folder called <VNF_NAME>_vnfd will be created with all the files required for a VNF package.
*Edit the descriptor file <VNF_NAME>_vnfd.yaml.
**By default, the descriptor is prepared for a single-VM VNF.
**Add as many VMs as required.
**Add also Internal VLDs as required.
*Add any artifacts needed by the VNF (eg, charm, icons, images etc ...) to the appropriate folder and make sure it is referenced in the descriptor.
*Once done, you can generate the tar.gz VNF package with the command:
./descriptor-packages/src/generate_descriptor_pkg.sh -t vnfd -N <VNF_NAME>_vnfd
#Note: the argument -N is optional and is intended to keep the package files after creating the package

'''Note''': If the descriptor is more complex such as a multi-VM VNF the GUI based composer tool is recommended to create the descriptor.

===Using the GUI based composer ===

==== Creating and onboarding a VNF descriptor ====

The GUI composer tool is recommended for editing complex VNFs such as multi-VM VNFs
* Bring up the OSM GUI.
* Navigate to the "catalog" page and click on the "+" sign to choose "ADD VNFD" option.
* A new VNF will be added to the canvas. By default the VNF will contain a single VM/VDU.
* Use the "model driven" editor on the right most side of the page to update the various fields in the VNF descriptor.
* Use the "ADD VDU" and "ADD IVLD" buttons to add additional VDUs and Internal VLDs needed by the VNF.
* Select the VDUs and VLDs created and update the fields as needed using the model driven editor on the right.
* For VDUs that need connection to an Internal VLD, add internal connection points to the VDU. Once added, the connection points will be visible on the canvas.
* Make the connection to Internal VLD and VDU by clicking in the VDU and drawing a line to the VLD.
* Once all the edits to the descriptor are completed, click "ONBOARD" to onboard the descriptor.

==== Exporting a VNF descriptor package ====

A descriptor that has been on-boarded (through package onboard or through the GUI composer) will be available for export to create a descriptor package.
#Note: Release1 does not include the artifacts that was in the on-boarded package in the exported package.

==== Adding additional artifacts to a VNF descriptor package ====

The release1 implementation does not allow the editing of artifacts within a VNF package. So only descriptors can be generated using the GUI composer tool.
If additional artifacts need to be included in the VNF package, then:
*Export the VNF package to myvnf.tar.gz.
*Untar the package using tar -zxvf myvnf.tar.gz.
*Copy the needed artifacts to the appropriate directory and update the descriptor to refer to them.
*Recreate the package using the CLI tool

==VNF with primitives==

You will have to create a proxy charm for the VNF. You can follow the general instructions below:
*Clone the descriptor-packages repo:
git clone https://osm.etsi.org/gerrit/osm/juju-charms
* Follow the instructions to create your own charm
https://osm.etsi.org/wikipub/index.php/Creating_your_own_VNF_charm_(Release_ONE)
You can then follow the ping-pong example in OSM descriptor packages to integrate the charm into VNF primitives

OSM Release ONE

2016-12-21T17:27:11Z

Chamarty: Add master install directions

Open Source MANO (OSM) is the open source community that aims to deliver 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.

{{#evu:https://www.youtube.com/watch?v=yBWSKwms47E
|alignment=right
}}

__TOC__

=Interaction with VIMs and VNFs=
The following figure shows OSM interaction with VIM and VNFs.

[[File:OSMconnectivity1.png|400px|OSM Release 1 connectivity 1]]

In simpler setups, OSM only requires a single interface as long as both VIM and VNF IP addresses are reachable

[[File:OSMconnectivity2.png|400px|OSM Release 1 connectivity 2]]

=Install OSM=

==Install from source==

All you need to run OSM Release One is a single server or VM with the following requirements:
* 8 CPUs, 16 GB RAM, 100GB disk and a single interface with Internet access
* Ubuntu16.04 as base image (http://releases.ubuntu.com/16.04/), configured to run LXD containers. If you don't have LXD configured, you can follow the instructions here ([[LXD configuration for OSM release 1|LXD configuration]]).

Note: If you wish to install OSM Release One from inside a LXD container, you will need to enable nested containers following instructions here ([[LXD within LXD|Nested containers]]).

Once you have prepared the host with the previous requirements, all you need to do is:
wget https://osm-download.etsi.org/ftp/osm-1.0-one/install_from_source.sh
chmod +x install_from_source.sh
./install_from_source.sh
If you need to install from latest master (recommended for advanced users only), please use,
./install_from_source.sh --develop

After some time, you will get a fresh OSM Release One installation. You can access to the UI in the following URL (user:admin, password: admin):

You can connect to the service via a web browser (Google Chrome version 50 or later is recommended). Open a browser and connect to https://1.2.3.4:8443 , replacing 1.2.3.4 with the IP address of your host. Note that it uses https, not http. Google Chrome is recommended. If you are using Firefox and plan to use the self-signed certificate provided in the installation, please follow instructions at [http://open.riftio.com/documentation/riftware/4.3/a/monitor/avoiding-selfsigned-certificate-warnings.htm#Using2 Using untrusted, self-signed certificates]
Alternatively, you can run Launchpad with trusted CA signed SSL certs as per [http://open.riftio.com/documentation/riftware/4.3/a/monitor/avoiding-selfsigned-certificate-warnings.htm#Using Using a certificate signed by a trusted CA]
or, run Launchpad with SSL disabled as per [http://open.riftio.com/documentation/riftware/4.3/a/user-guide/run-launchpad-with-ssl-disabled.htm?Highlight=disable Run Launchpad with SSL Disabled]

[[File:OSMloginWindow.png|400px|OSM login window]]

Make sure that port 8443 is accessible, as well as the following required ports: 8000, 4567, 8008, 80, 9090.

As a result of the installation, three LXD containers are created in the host: RO, VCA, and SO-ub (running the SO and the UI), as shown in the figure below.

[[File:OSMcontainers.png|400px|OSM Release ONE installation result]]

=Adding a VIM account=
Before proceeding, make sure that you have a site with a VIM configured to run with OSM. Three different kinds of VIMs are currently supported by OSM:
*OpenVIM. Check the following link to know how to install and use openvim for OSM: [[OpenVIM installation (Release One)]]
*OpenStack. Check the following link to learn how to configure OpenStack to be used by OSM: [[Openstack configuration (Release ONE)]]
*VMware vCloud Director. Check the following link to learn how to configure VMware VCD to be used by OSM: [[Configuring VMware vCloud Director for OSM Release One]]

==OpenVIM site==
*Go into the RO container:
lxc exec RO -- bash
*Execute the following commands, using the appropriate parameters (e.g. site name: "openvim-site", IP address: 10.10.10.10, VIM tenant: "osm")
export OPENMANO_TENANT=osm
openmano datacenter-create openvim-site http://10.10.10.10:9080/openvim --type openvim --description "Openvim site"
openmano datacenter-attach openvim-site --vim-tenant-name=osm
openmano datacenter-list
exit #or Ctrl+D to get out of the RO container

==Openstack site==
*Go into the RO container:
lxc exec RO -- bash
*Execute the following commands, using the appropriate parameters (e.g. site name: "openstack-site", IP address: 10.10.10.11, VIM tenant: "admin", user: "admin", password: "userpwd")
export OPENMANO_TENANT=osm
openmano datacenter-create openstack-site http://10.10.10.11:5000/v2.0 --type openstack --description "OpenStack site"
openmano datacenter-attach openstack-site --user=admin --password=userpwd --vim-tenant-name=admin
openmano datacenter-list
exit #or Ctrl+D to get out of the RO container

==VMware site==
*Go into the RO container:
lxc exec RO -- bash
*Execute the following commands, using the appropriate parameters (e.g. site name: "vmware-site", IP address: 10.10.10.12, VIM tenant: "vmware-tenant", user: "osm", password: "osm4u", admin user: "admin", admin password: "adminpwd")
openmano datacenter-create vmware-site https://10.10.10.12 --type vmware --description "VMware site" --config '{admin_password: adminpwd, admin_username: admin}'
openmano datacenter-attach vmware-site --user=osm --password=osm4u --vim-tenant-name=vmware-tenant
openmano datacenter-list
exit #or Ctrl+D to get out of the RO container

Note: The name of the site/datacenter "vmware-site" has to match the name of the organization of "vCloud Director". Inside this organization the tenant "vmware-tenant" must exist

=Deploying your first Network Service=
In this example we will deploy the following Network Service, consisting of two simple VNFs based on CirrOS connected by a simple VLD.

[[File:cirros_2vnf_ns.png|500px|NS with 2 CirrOS VNF]]

Before going on, download the required VNF and NS packages from this URL: https://osm-download.etsi.org/ftp/examples/cirros_2vnf_ns/

==Uploading VNF image to the VIM==
Get the cirros 0.3.4 image from the following link: http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img

Then, onboard the image into the VIM. The instruction differs from one VIM to another:
*In Openstack:
openstack image create --file="./cirros-0.3.4-x86_64-disk.img" --container-format=bare --disk-format=qcow2 --public --property location="/mnt/powervault/virtualization/osm/CirrOS/cirros-0.3.4-x86_64-disk.img" cirros034
*In openvim:
openvim image-create --name cirros034 --path /mnt/powervault/virtualization/osm/CirrOS/cirros-0.3.4-x86_64-disk.img

==Onboarding a VNF==
*From the UI:
**Go to Catalog
**Click on the import button, then VNFD
**Drag and drop the VNF package file cirros_vnf.tar.gz in the importing area.
[[File:onboardingVNF.png|300px|Onboarding a VNF]]
*From the SO CLI:
**From the SO-ub container ("lxc exec SO-ub bash"), execute the following:
/root/SO/rwlaunchpad/plugins/rwlaunchpadtasklet/scripts/onboard_pkg -s 127.0.0.1 -u cirros_vnf.tar.gz

==Onboarding a NS==
*From the UI:
**Go to Catalog
**Click on the import button, then NSD
**Drag and drop the NS package file cirros_2vnf_ns.tar.gz in the importing area.
*From the SO CLI:
**From the SO-ub container ("lxc exec SO-ub bash"), execute the following command:
/root/SO/rwlaunchpad/plugins/rwlaunchpadtasklet/scripts/onboard_pkg -s 127.0.0.1 -u cirros_2vnf_ns.tar.gz

==Instantiating the NS==
*From the UI:
**Go to Launchpad > Instantiate
**Select the NS descriptor to be instantiated, and click on Next
**Add a name to the NS instance, and click on Launch.
[[File:instantiatingNS.png|300px|Instantiating a NS (step 1)]] [[File:instantiatingNS-step2.png|400px|Instantiating a NS (step 2)]]
*From the SO CLI:
**From the SO-ub container ("lxc exec SO-ub bash"), execute the following command:

/root/SO/rwlaunchpad/plugins/rwlaunchpadtasklet/scripts/onboard_pkg -i <ns-instance-name> -d <nsd-id> -D <data-center-id>

Note: The nsd-id and data-center-id need to be replaced with the values from your setup.
Issue the following commands from the SO CLI(See the next section "Accessing CLI for viewing instantiated NS details" on how to access SO CLI) to determine the nsd-id and data-center-id,

** <code>show nsd-catalog nsd </code> - Displays the nsds in the catalog. Find the id of the cirros_2vnf_nsd NSD
** <code>show data centers</code> - Displays the list of data centers configured in the RO. Choose the data center where the network service need to be instantiated.

Wait for the message that the NS has been successfully deployed, and that's all!

== Accessing CLI for viewing instantiated NS details ==

From the SO-ub container ("lxc exec SO-ub bash"), execute the following command to bring up SO CLI (username:admin password:admin)

/usr/rift/rift-shell -r -i /usr/rift -a /usr/rift/.artifacts -- rwcli --rift_var_root /usr/rift/var/rift

The CLI can be used to both configure the system and show operational-data from the system. For instance:
rift# show nsd-catalog # show the nsd catalog
rift# show vnfd-catalog # show vnfd catalog
rift# show ns-instance-config nsr # Lists instantiated network service
rift# show ns-instance-opdata nsr # Lists of instantiated network service op-data

=Additional information=

*Check other VNF packages and NS packages in the links below:
**VNF packages: https://osm-download.etsi.org/ftp/osm-1.0-one/vnf-packages
**NS packages: https://osm-download.etsi.org/ftp/osm-1.0-one/ns-packages
*[[Deploying advanced Network Services (Release ONE)|Deploy advanced Network Services]]
*[[Creating your own VNF package (Release ONE)|Create your own VNF package]]
*[[Reference VNF and NS Descriptors (Release ONE)|Reference VNF and NS Descriptors]]
*[[How to report issues (Release ONE)|Have you detected any bug? Check this guide to see how to report issues]]
*[[Logs and troubleshooting (Release ONE)|Logs and troubleshooting]]
*[[Release ONE Data Model details|Data Model Details]]
*[https://osm.etsi.org/images/OSM-Whitepaper-TechContent-ReleaseONE-FINAL.pdf OSM White Paper - Release ONE Technical Overview]
*[[Release ONE Technical FAQ|Technical FAQ]]

{{Feedback}}

Workflow with OSM tools

2016-12-06T15:22:12Z

Chamarty: Use curl instead of scp for commit-msg hooks

__TOC__

= Login to OSM portal =
# Go to OSM portal: https://osm.etsi.org/
# Login using your username and password

'''Note:'''
* If you are '''[[Participate|contributing on behalf of your company]]''', you should login with your '''ETSI Online Account (EOL)'''.
** If your company is not yet an '''[https://portal.etsi.org/TBSiteMap/OSM/ListofOSMMembers.aspx OSM Member or Participant]''', you can check here '''[https://osm.etsi.org/welcome/#join how to join OSM as an organization]'''
** If your company has '''already joined OSM but you do not have an EOL account''' yet, you can '''[http://webapp.etsi.org/createaccount/ request an EOL account]'''

* If you are an '''individual contributor''', you can '''[https://osm.etsi.org/index2.php?page=page_register.php create your OSM account online]'''.

If you need any help, contact us at [mailto:OSMsupport@etsi.org OSMsupport@etsi.org]

= Report a bug on Bugzilla =
# Go to the OSM Portal
# Click on '''Bugzilla''' menu on the portal menu bar.
# Click on "new" on Bugzilla menu bar.
# Choose the product, e.g. "OSM".
# Complete the bug form. If you know, choose the component, e.g OpenMANO, Riftware, UI, SO, etc.
# Enter the bug summary, description, attachement, etc.
# Click on the "Submit Bug" button to confirm.
# A bug id is generated (e.g. Bug 6 -Small Error)

= Clone your project =
# Clone a '''git''' repository, for example: <pre> git clone https://osm.etsi.org/gerrit/osm/RO.git </pre>
# Enter your username
# Enter you password
# It is recommended to install the Gerrit commit-msg hook for the cloned repository in order to automatically insert a Change-Id tag in commit messages. You can install it by entering the following command for RO repository <pre> curl -Lo RO/.git/hooks/commit-msg http://osm.etsi.org/gerrit/tools/hooks/commit-msg </pre> You then need to make the hook executable <pre> chmod u+x RO/.git/hooks/commit-msg </pre> More information about the Gerrit commit-msg hook can be found here https://git.eclipse.org/r/Documentation/cmd-hook-commit-msg.html

'''Note''':
* You can find all the project repository URLs on '''[https://osm.etsi.org/gitweb/ Gitweb]''' or on '''[https://osm.etsi.org/gerrit/ Gerrit]'''
** On Gitweb
**# Click on '''Gitweb''' menu on the portal menu bar.
**# Select a product to see the available cloning URLs
** On Gerrit
**# Click on '''Gerrit''' menu on the portal menu bar.
**# Click on "Projects" menu on the Gerrit menu bar.
**# Click on "List" menu.
**# Select a product to see the available cloning URLs.

= Configure your Git environment =
# Configure your git username globally: <pre> git config --global user.name <username> </pre>
# Configure your git email address: <pre> git config --global user.email <email> </pre>
# Check your git configuration: <pre> git config --list </pre>
'''Note: Your email address will be visible on commits to Git.
If you'd like to keep your email address private, you can mask your email as follows:
if your email is <name@company.com> you can set user.email to <hidden@company.com>
This allows other users to identify you as a contributor (with your user name) and
Git Stats to keep track of your company's contributions (with the email domain)

In case you are using git in the same computer for other open source projects, you can restrict your git variables to the local folder: <pre>git config --local user.name <username>
git config --local user.email <email> </pre>

= Commit changes to your local project =
# go to the "openmano" folder <pre>cd osm/openmano</pre>
# Make some changes on the source (e.g. add a line to the "example-file")
# Stage the change. <pre> git add example-file </pre>
# Commit the change to your local repository. You can add a bug id in your commit message to link the bug to your contribution <pre> git commit -s -m "Bug 2 fixed!!" </pre>
# You can see your commit message and update it, if needed, using the following command: <pre>git commit --amend </pre>

==Developer's Certificate of Origin==
* The "-s" parameter enables to Sign the contribution. It adds the following line at the end of your commit message:
<pre> Signed-off-by: Random J Developer <random@developer.example.org></pre>

* The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as a open-source patch. The rules are pretty simple: signing a contribution means that you can certify the below:

<pre>
Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
</pre>

= Push your contribution to Gerrit =
# To avoid merge conflicts, it is recommended to do a pull with rebase before pushing your contribution in order to merge latest changes made by other users. <pre>git pull --rebase</pre> Note: you can force git to use always the --rebase option with <pre>git config --local pull.rebase true</pre>
# Push your commits to '''Gerrit''' for Code Review using the following command <pre>git push origin HEAD:refs/for/master</pre> <pre>#use 'v1.0' instead of 'master' for contributing to v1.0 branch </pre>
<pre> NOTE: you can also configure git to push always to the desired branch.
git config --local remote.origin.push HEAD:refs/for/master
git config --local remote.origin.push HEAD:refs/for/v1.0
</pre>
# Enter your username.
# Enter your password.
# You can review your contribution on '''Gerrit''' web interface

'''Notes:'''
* The following actions are execution automatically after pushing any contribution to Gerrit:
** '''Gerrit''' reports the new contribution state to the corresponding bug in '''Bugzilla'''
** '''Gerrit''' notifies '''Jenkins''' to build the new contribution.

= Gerrit Notifications =
Gerrit sends email notifications to:
*Owner of the change
*Reviewers of the change
*Project watchers

Each user can configure his own watched projects and branches in the "settings/watched project" menu. Email notifications can be sent for New Changes, New Patch Sets, All Comments, Submitted Changes and Abandoned Changes.

Link: [https://osm.etsi.org/gerrit/#/settings/projects https://osm.etsi.org/gerrit/#/settings/projects] (you can navigate there from the Gerrit console by clicking on the arrow by your login on the top right corner)

= Continuous Integration =
# '''Jenkins''' builds, tests the new contribution, and reports the result on its web interface.
# '''Jenkins''' votes on the contribution using '''“Code-Verif”''' (-1, +1) on '''Gerrit'''.

= Code Review =
# Other '''contributors''' and '''MDG Committers''' can comment the new contribution and vote using '''“Code-Review”''' (-1, 0, +1) on '''Gerrit'''.
# The '''MDG Leader''' can comment the new contribution and votes using '''“Code-Review”''' (-2, -1, 0, +1, +2) on '''Gerrit'''.

= Merge the contribution =
# The '''MDG Leader''' can "Submit" the change only if +1 '''"Code-Verif"''' (from '''Jenkins''') and at least one +2 '''"Code-Review"'''.
# '''Gerrit''' reports the result of the code review to the corresponding bug in '''Bugzilla'''

{{Feedback}}

Reference VNF and NS Descriptors (Release ONE)

2016-12-01T13:18:14Z

Chamarty: Updated VNF22

The following reference examples are provided to help VNF vendors to create their own descriptors (NSD, VNFD) usable in OSM.

= Reference NS#1: Testing an endpoint VNF =

The following network service captures a simple test setup where a VNF is tested with a traffic generator VNF (or a simple VNF/VM with a basic client application). For simplicity, this network service assumes that the VNF under test is the endpoint of a given service (e.g. DNS, AAA, etc.) and does not require special conditions or resource allocation besides the usual in a standard cloud environments.

[[File:example_ns_1.png | 450px | right | Reference NS #1: Testing an endpoint VNF]]

In this example, unless otherwise specified in the description, the following defaults apply:
* CPs are regular para-virtualized interfaces (VirtIO or equivalent).
* VLs provide E-LAN connectivity via regular (overlay) networks provided by the VIM.
* VLs provide IP addressing via DHCP if applicable.
* Mapping between internal and external CPs may be either direct (as aliases) or via an intermediate VL.
* VIM+NFVI can guarantee predictable ordering of guest interfaces' virtual PCI addresses.

In the case of REF_NS_1:
* When deploying the NS, VL1 would be typically mapped to a pre-created VIM network intended to provide management IP address to VNFs via DHCP.
* DHCP in VL2 may be optional.

== Reference VNF#11: Endpoint VNF ==
[[File:ref_vnf_11.png | 350px | right | Reference VNF#11: Endpoint]]

=== Description in common language ===
* '''Name:''' Ref_VNF_11
** '''Component:''' Ref_VM1
*** '''Memory:''' 2 GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 8 GB
*** '''Image:''' ref_vm1.qcow2
** '''Component:''' Ref_VM2
*** '''Memory:''' 4GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 16GB
*** '''Image:''' ref_vm2.qcow2
** '''Internal Virtual Link:''' VL12
*** No DHCP server is enabled.
*** Static addressing may be used at CP iface11 and CP iface21.

=== OSM VNF descriptor for VNF#11 ===
[[File:Ref_VNF_11.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: mgmt0
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ VM1 and VM2
vnfd:id: 287671e2-2858-48cf-a13c-b4cb1351aa9f
vnfd:name: Ref_VNF_11
vnfd:short-name: Ref_VNF_11
vnfd:vdu:
- vnfd:external-interface:
- vnfd:name: iface10
vnfd:virtual-interface:
vnfd:type: OM-MGMT
vnfd:vnfd-connection-point-ref: mgmt0
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm1.qcow2
vnfd:name: Ref_VM1
vnfd:vm-flavor:
vnfd:memory-mb: '2048'
vnfd:storage-gb: '8'
vnfd:vcpu-count: '2'
vnfd:vendor: ETSI
vnfd:version: '1.0'
</nowiki>

== Reference VNF#21: Generator 1 port ==
[[File:ref_vnf_21.png | 350px | right | Reference VNF#21: Generator 1 port]]

=== Description in common language ===
* '''Name:''' Ref_VNF_21
** '''Component:''' Ref_VM5
*** '''Memory:''' 1 GB
*** '''CPU:''' 1 vCPU
*** '''Storage:''' 16 GB
*** '''Image:''' ref_vm21.qcow2

=== OSM VNF descriptor for VNF#21 ===
[[File:Ref_VNF_21.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: cp1
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ one VDU
vnfd:id: d6c25720-895a-40a2-b303-b2a98d10674c
vnfd:name: Ref_Vnf_21
vnfd:short-name: Ref_Vnf_21
vnfd:vdu:
- vnfd:external-interface:
- vnfd:name: eth0
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:vnfd-connection-point-ref: cp1
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm21.qcow2
vnfd:name: Ref_VM5
vnfd:vm-flavor:
vnfd:memory-mb: '1024'
vnfd:storage-gb: '16'
vnfd:vcpu-count: '1'
vnfd:vendor: ETSI
vnfd:version: '1.0'
</nowiki>

== OSM NS descriptor for NS#1 ==
[[File:Ref_NS1.tar.gz]]
[[NS1 Yaml descriptor]]
<nowiki>
nsd:nsd-catalog:
nsd:nsd:
- nsd:constituent-vnfd:
- nsd:member-vnf-index: '1'
nsd:start-by-default: 'true'
nsd:vnfd-id-ref: d6c25720-895a-40a2-b303-b2a98d10674c
- nsd:member-vnf-index: '2'
nsd:vnfd-id-ref: 287671e2-2858-48cf-a13c-b4cb1351aa9f
nsd:description: Reference NS 1
nsd:id: 9b684262-ded5-4d43-82d3-5e2bf69b7446
nsd:name: Ref_NS_1
nsd:vendor: ETSI
nsd:vld:
- nsd:description: Mgmt VL
nsd:id: 54c04
nsd:name: VL1
nsd:short-name: VL1
nsd:type: ELAN
nsd:vendor: ETSI
nsd:vnfd-connection-point-ref:
- nsd:member-vnf-index-ref: '1'
nsd:vnfd-connection-point-ref: mgmt
nsd:vnfd-id-ref: d6c25720-895a-40a2-b303-b2a98d10674c
- nsd:member-vnf-index-ref: '2'
nsd:vnfd-connection-point-ref: mgmt0
nsd:vnfd-id-ref: 287671e2-2858-48cf-a13c-b4cb1351aa9f
</nowiki>

= Reference NS #2: Testing a middle point VNF =
[[File:example_ns_2.png | 400px | right | Reference NS #2: Testing a middle point VNF]]

The following network service captures a more advanced test setup where the VNF under test is a middlepoint in the communication (e.g. router, EPC) and might require special conditions or resource allocation and connectivity foreseen in NFV ISG specs. In this case, the traffic generator VNF behaves as source and sink of traffic and might also require special resource allocation.

In this example, unless otherwise specified in the description, the following applies:
* Same defaults as in NS#1
* vCPUs must be pinned to dedicated physical CPUs, with no over subscription.
* CPUs, memory and interfaces (if applicable) to be assigned to a given VM should belong to the same socket (NUMA awareness).
* Memory assigned to VMs should be backed by host's huge pages memory.
* VL2 and VL3 are E-Line underlay connectivity. No DHCP is required.

== Reference VNF#12: Middle point VNF ==
[[File:ref_vnf_12.png | 400px | right | Reference VNF#12: Middle point]]

=== Description in common language ===
* '''Name:''' Ref_VNF_12
** '''Component:''' Ref_VM3
*** '''Memory:''' 2 GB huge pages
*** '''CPU:''' 2 vCPU (= CPU)
*** '''Storage:''' 8 GB
*** '''Image:''' ref_vm3.qcow2
** '''Component:''' Ref_VM4
*** '''Memory:''' 4GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 16GB
*** '''Image:''' ref_vm4.qcow2
** '''Connection Point:''' iface42 (west)
*** '''Type:''' Passthrough
** '''Connection Point:''' iface43 (east)
*** '''Type:''' SR-IOV

=== OSM VNF descriptor for VNF#12 ===
[[File:Ref_VNF_12.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: mgmt0
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ two VDU
vnfd:id: abae3d33-36ec-4707-95aa-e48907bf2442
vnfd:name: Ref_Vnf_12
vnfd:short-name: Ref_Vnf_12
vnfd:vdu:
- vnfd:description: Middlepoint
vnfd:external-interface:
- vnfd:name: iface30
vnfd:virtual-interface:
vnfd:type: OM-MGMT
vnfd:vnfd-connection-point-ref: mgmt0
vnfd:guest-epa:
vnfd:cpu-pinning-policy: DEDICATED
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm3.qcow2
vnfd:internal-connection-point:
- vnfd:id: 5f813
vnfd:name: icp0
vnfd:type: VPORT
vnfd:internal-interface:
- vnfd:name: iface31
vnfd:vdu-internal-connection-point-ref: 5f813
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:name: Ref_VM3
vnfd:vm-flavor:
vnfd:memory-mb: '2048'
vnfd:storage-gb: '8'
vnfd:vcpu-count: '2'
- vnfd:external-interface:
- vnfd:name: iface42
vnfd:virtual-interface:
vnfd:type: PCI-PASSTHROUGH
- vnfd:name: iface43
vnfd:virtual-interface:
vnfd:type: SR-IOV
vnfd:guest-epa:
vnfd:cpu-pinning-policy: DEDICATED
vnfd:id: e526e
vnfd:internal-connection-point:
- vnfd:id: 9ec35
vnfd:name: icp0
vnfd:type: VPORT
vnfd:internal-interface:
- vnfd:name: iface41
vnfd:vdu-internal-connection-point-ref: 9ec35
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:vendor: ETSI
vnfd:version: '1.0'
</nowiki>

== Reference VNF#22: Generator 2 ports ==

[[File:ref_vnf_22.png | 400px | right | Reference VNF#22: Generator 2 ports]]

=== Description in common language ===
* '''Name:''' Ref_VNF_22
** '''Component:''' Ref_VM6
*** '''Memory:''' 1 GB huge pages
*** '''CPU:''' 1 vCPU (= CPU)
*** '''Storage:''' 16 GB
*** '''Image:''' ref_vm22.qcow2
** '''Connection Point:''' iface61 (west)
*** '''Type:''' Passthrough
** '''Connection Point:''' iface62 (east)
*** '''Type:''' SR-IOV

=== OSM VNF descriptor for VNF#22 ===
[[File:Ref_VNF_22.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: cp1
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ one VDU
vnfd:id: c993c90e-857f-499e-aad3-74f1667216d2
vnfd:name: Ref_VNF_22
vnfd:short-name: Ref_VNF_22
vnfd:vdu:
- vnfd:external-interface:
- vnfd:name: eth0
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:vnfd-connection-point-ref: cp1
- vnfd:name: iface61
vnfd:virtual-interface:
vnfd:type: PCI-PASSTHROUGH
- vnfd:name: iface62
vnfd:virtual-interface:
vnfd:type: SR-IOV
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm22.qcow2
vnfd:name: Ref_VM6
vnfd:vm-flavor:
vnfd:memory-mb: '1024'
vnfd:storage-gb: '16'
vnfd:vcpu-count: '1'
vnfd:vendor: ETSI
vnfd:version: '1.0'
</nowiki>

== OSM NS descriptor for NS#2 ==
[[File:Ref_NS_2.tar.gz]]
<nowiki>
nsd:nsd-catalog:
nsd:nsd:
- nsd:constituent-vnfd:
- nsd:member-vnf-index: '1'
nsd:vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- nsd:member-vnf-index: '2'
nsd:vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
nsd:description: Reference NS2
nsd:id: cbd6d406-57ff-40ee-8155-8013a40f6bad
nsd:name: Ref_NS_2
nsd:vendor: ETSI
nsd:vld:
- nsd:id: '97465'
nsd:name: Mgmt
nsd:vnfd-connection-point-ref:
- nsd:member-vnf-index-ref: '1'
nsd:vnfd-connection-point-ref: mgmt0
nsd:vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- nsd:member-vnf-index-ref: '2'
nsd:vnfd-connection-point-ref: mgmt
nsd:vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
- nsd:id: f66e6
nsd:vnfd-connection-point-ref:
- nsd:member-vnf-index-ref: '1'
nsd:vnfd-connection-point-ref: east
nsd:vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- nsd:member-vnf-index-ref: '2'
nsd:vnfd-connection-point-ref: east
nsd:vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
</nowiki>

Reference VNF and NS Descriptors (Release ONE)

2016-12-01T13:16:15Z

Chamarty: Add descriptors inline

The following reference examples are provided to help VNF vendors to create their own descriptors (NSD, VNFD) usable in OSM.

= Reference NS#1: Testing an endpoint VNF =

The following network service captures a simple test setup where a VNF is tested with a traffic generator VNF (or a simple VNF/VM with a basic client application). For simplicity, this network service assumes that the VNF under test is the endpoint of a given service (e.g. DNS, AAA, etc.) and does not require special conditions or resource allocation besides the usual in a standard cloud environments.

[[File:example_ns_1.png | 450px | right | Reference NS #1: Testing an endpoint VNF]]

In this example, unless otherwise specified in the description, the following defaults apply:
* CPs are regular para-virtualized interfaces (VirtIO or equivalent).
* VLs provide E-LAN connectivity via regular (overlay) networks provided by the VIM.
* VLs provide IP addressing via DHCP if applicable.
* Mapping between internal and external CPs may be either direct (as aliases) or via an intermediate VL.
* VIM+NFVI can guarantee predictable ordering of guest interfaces' virtual PCI addresses.

In the case of REF_NS_1:
* When deploying the NS, VL1 would be typically mapped to a pre-created VIM network intended to provide management IP address to VNFs via DHCP.
* DHCP in VL2 may be optional.

== Reference VNF#11: Endpoint VNF ==
[[File:ref_vnf_11.png | 350px | right | Reference VNF#11: Endpoint]]

=== Description in common language ===
* '''Name:''' Ref_VNF_11
** '''Component:''' Ref_VM1
*** '''Memory:''' 2 GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 8 GB
*** '''Image:''' ref_vm1.qcow2
** '''Component:''' Ref_VM2
*** '''Memory:''' 4GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 16GB
*** '''Image:''' ref_vm2.qcow2
** '''Internal Virtual Link:''' VL12
*** No DHCP server is enabled.
*** Static addressing may be used at CP iface11 and CP iface21.

=== OSM VNF descriptor for VNF#11 ===
[[File:Ref_VNF_11.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: mgmt0
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ VM1 and VM2
vnfd:id: 287671e2-2858-48cf-a13c-b4cb1351aa9f
vnfd:name: Ref_VNF_11
vnfd:short-name: Ref_VNF_11
vnfd:vdu:
- vnfd:external-interface:
- vnfd:name: iface10
vnfd:virtual-interface:
vnfd:type: OM-MGMT
vnfd:vnfd-connection-point-ref: mgmt0
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm1.qcow2
vnfd:name: Ref_VM1
vnfd:vm-flavor:
vnfd:memory-mb: '2048'
vnfd:storage-gb: '8'
vnfd:vcpu-count: '2'
vnfd:vendor: ETSI
vnfd:version: '1.0'
</nowiki>

== Reference VNF#21: Generator 1 port ==
[[File:ref_vnf_21.png | 350px | right | Reference VNF#21: Generator 1 port]]

=== Description in common language ===
* '''Name:''' Ref_VNF_21
** '''Component:''' Ref_VM5
*** '''Memory:''' 1 GB
*** '''CPU:''' 1 vCPU
*** '''Storage:''' 16 GB
*** '''Image:''' ref_vm21.qcow2

=== OSM VNF descriptor for VNF#21 ===
[[File:Ref_VNF_21.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: cp1
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ one VDU
vnfd:id: d6c25720-895a-40a2-b303-b2a98d10674c
vnfd:name: Ref_Vnf_21
vnfd:short-name: Ref_Vnf_21
vnfd:vdu:
- vnfd:external-interface:
- vnfd:name: eth0
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:vnfd-connection-point-ref: cp1
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm21.qcow2
vnfd:name: Ref_VM5
vnfd:vm-flavor:
vnfd:memory-mb: '1024'
vnfd:storage-gb: '16'
vnfd:vcpu-count: '1'
vnfd:vendor: ETSI
vnfd:version: '1.0'
</nowiki>

== OSM NS descriptor for NS#1 ==
[[File:Ref_NS1.tar.gz]]
[[NS1 Yaml descriptor]]
<nowiki>
nsd:nsd-catalog:
nsd:nsd:
- nsd:constituent-vnfd:
- nsd:member-vnf-index: '1'
nsd:start-by-default: 'true'
nsd:vnfd-id-ref: d6c25720-895a-40a2-b303-b2a98d10674c
- nsd:member-vnf-index: '2'
nsd:vnfd-id-ref: 287671e2-2858-48cf-a13c-b4cb1351aa9f
nsd:description: Reference NS 1
nsd:id: 9b684262-ded5-4d43-82d3-5e2bf69b7446
nsd:name: Ref_NS_1
nsd:vendor: ETSI
nsd:vld:
- nsd:description: Mgmt VL
nsd:id: 54c04
nsd:name: VL1
nsd:short-name: VL1
nsd:type: ELAN
nsd:vendor: ETSI
nsd:vnfd-connection-point-ref:
- nsd:member-vnf-index-ref: '1'
nsd:vnfd-connection-point-ref: mgmt
nsd:vnfd-id-ref: d6c25720-895a-40a2-b303-b2a98d10674c
- nsd:member-vnf-index-ref: '2'
nsd:vnfd-connection-point-ref: mgmt0
nsd:vnfd-id-ref: 287671e2-2858-48cf-a13c-b4cb1351aa9f
</nowiki>

= Reference NS #2: Testing a middle point VNF =
[[File:example_ns_2.png | 400px | right | Reference NS #2: Testing a middle point VNF]]

The following network service captures a more advanced test setup where the VNF under test is a middlepoint in the communication (e.g. router, EPC) and might require special conditions or resource allocation and connectivity foreseen in NFV ISG specs. In this case, the traffic generator VNF behaves as source and sink of traffic and might also require special resource allocation.

In this example, unless otherwise specified in the description, the following applies:
* Same defaults as in NS#1
* vCPUs must be pinned to dedicated physical CPUs, with no over subscription.
* CPUs, memory and interfaces (if applicable) to be assigned to a given VM should belong to the same socket (NUMA awareness).
* Memory assigned to VMs should be backed by host's huge pages memory.
* VL2 and VL3 are E-Line underlay connectivity. No DHCP is required.

== Reference VNF#12: Middle point VNF ==
[[File:ref_vnf_12.png | 400px | right | Reference VNF#12: Middle point]]

=== Description in common language ===
* '''Name:''' Ref_VNF_12
** '''Component:''' Ref_VM3
*** '''Memory:''' 2 GB huge pages
*** '''CPU:''' 2 vCPU (= CPU)
*** '''Storage:''' 8 GB
*** '''Image:''' ref_vm3.qcow2
** '''Component:''' Ref_VM4
*** '''Memory:''' 4GB
*** '''CPU:''' 2 vCPU
*** '''Storage:''' 16GB
*** '''Image:''' ref_vm4.qcow2
** '''Connection Point:''' iface42 (west)
*** '''Type:''' Passthrough
** '''Connection Point:''' iface43 (east)
*** '''Type:''' SR-IOV

=== OSM VNF descriptor for VNF#12 ===
[[File:Ref_VNF_12.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: mgmt0
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ two VDU
vnfd:id: abae3d33-36ec-4707-95aa-e48907bf2442
vnfd:name: Ref_Vnf_12
vnfd:short-name: Ref_Vnf_12
vnfd:vdu:
- vnfd:description: Middlepoint
vnfd:external-interface:
- vnfd:name: iface30
vnfd:virtual-interface:
vnfd:type: OM-MGMT
vnfd:vnfd-connection-point-ref: mgmt0
vnfd:guest-epa:
vnfd:cpu-pinning-policy: DEDICATED
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm3.qcow2
vnfd:internal-connection-point:
- vnfd:id: 5f813
vnfd:name: icp0
vnfd:type: VPORT
vnfd:internal-interface:
- vnfd:name: iface31
vnfd:vdu-internal-connection-point-ref: 5f813
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:name: Ref_VM3
vnfd:vm-flavor:
vnfd:memory-mb: '2048'
vnfd:storage-gb: '8'
vnfd:vcpu-count: '2'
- vnfd:external-interface:
- vnfd:name: iface42
vnfd:virtual-interface:
vnfd:type: PCI-PASSTHROUGH
- vnfd:name: iface43
vnfd:virtual-interface:
vnfd:type: SR-IOV
vnfd:guest-epa:
vnfd:cpu-pinning-policy: DEDICATED
vnfd:id: e526e
vnfd:internal-connection-point:
- vnfd:id: 9ec35
vnfd:name: icp0
vnfd:type: VPORT
vnfd:internal-interface:
- vnfd:name: iface41
vnfd:vdu-internal-connection-point-ref: 9ec35
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:vendor: ETSI
vnfd:version: '1.0'
</nowiki>

== Reference VNF#22: Generator 2 ports ==

[[File:ref_vnf_22.png | 400px | right | Reference VNF#22: Generator 2 ports]]

=== Description in common language ===
* '''Name:''' Ref_VNF_22
** '''Component:''' Ref_VM6
*** '''Memory:''' 1 GB huge pages
*** '''CPU:''' 1 vCPU (= CPU)
*** '''Storage:''' 16 GB
*** '''Image:''' ref_vm22.qcow2
** '''Connection Point:''' iface61 (west)
*** '''Type:''' Passthrough
** '''Connection Point:''' iface62 (east)
*** '''Type:''' SR-IOV

=== OSM VNF descriptor for VNF#22 ===
[[File:Ref_VNF_22.tar.gz]]
<nowiki>
vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: mgmt0
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ two VDU
vnfd:id: abae3d33-36ec-4707-95aa-e48907bf2442
vnfd:name: Ref_Vnf_12
vnfd:short-name: Ref_Vnf_12
vnfd:vdu:
- vnfd:description: Middlepoint
vnfd:external-interface:
- vnfd:name: iface30
vnfd:virtual-interface:
vnfd:type: OM-MGMT
vnfd:vnfd-connection-point-ref: mgmt0
vnfd:guest-epa:
vnfd:cpu-pinning-policy: DEDICATED
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm3.qcow2
vnfd:internal-connection-point:
- vnfd:id: 5f813
vnfd:name: icp0
vnfd:type: VPORT
vnfd:internal-interface:
- vnfd:name: iface31
vnfd:vdu-internal-connection-point-ref: 5f813
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:name: Ref_VM3
vnfd:vm-flavor:
vnfd:memory-mb: '2048'
vnfd:storage-gb: '8'
vnfd:vcpu-count: '2'
- vnfd:external-interface:
- vnfd:name: iface42
vnfd:virtual-interface:
vnfd:type: PCI-PASSTHROUGH
- vnfd:name: iface43
vnfd:virtual-interface:
vnfd:type: SR-IOV
vnfd:guest-epa:
vnfd:cpu-pinning-policy: DEDICATED
vnfd:id: e526e
vnfd:internal-connection-point:
- vnfd:id: 9ec35
vnfd:name: icp0
vnfd:type: VPORT
vnfd:internal-interface:
- vnfd:name: iface41
vnfd:vdu-internal-connection-point-ref: 9ec35
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:vendor: ETSI
vnfd:version: '1.0'

</nowiki>

== OSM NS descriptor for NS#2 ==
[[File:Ref_NS_2.tar.gz]]
<nowiki>
nsd:nsd-catalog:
nsd:nsd:
- nsd:constituent-vnfd:
- nsd:member-vnf-index: '1'
nsd:vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- nsd:member-vnf-index: '2'
nsd:vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
nsd:description: Reference NS2
nsd:id: cbd6d406-57ff-40ee-8155-8013a40f6bad
nsd:name: Ref_NS_2
nsd:vendor: ETSI
nsd:vld:
- nsd:id: '97465'
nsd:name: Mgmt
nsd:vnfd-connection-point-ref:
- nsd:member-vnf-index-ref: '1'
nsd:vnfd-connection-point-ref: mgmt0
nsd:vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- nsd:member-vnf-index-ref: '2'
nsd:vnfd-connection-point-ref: mgmt
nsd:vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
- nsd:id: f66e6
nsd:vnfd-connection-point-ref:
- nsd:member-vnf-index-ref: '1'
nsd:vnfd-connection-point-ref: east
nsd:vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- nsd:member-vnf-index-ref: '2'
nsd:vnfd-connection-point-ref: east
nsd:vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
</nowiki>

NS2 Yaml descriptor

2016-11-30T20:50:55Z

Chamarty: NS2 initial descriptor

nsd:nsd-catalog:
nsd:nsd:
- nsd:constituent-vnfd:
- nsd:member-vnf-index: '1'
nsd:vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- nsd:member-vnf-index: '2'
nsd:vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
nsd:description: Reference NS2
nsd:id: cbd6d406-57ff-40ee-8155-8013a40f6bad
nsd:name: Ref_NS_2
nsd:vendor: ETSI
nsd:vld:
- nsd:id: '97465'
nsd:name: Mgmt
nsd:vnfd-connection-point-ref:
- nsd:member-vnf-index-ref: '1'
nsd:vnfd-connection-point-ref: mgmt0
nsd:vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- nsd:member-vnf-index-ref: '2'
nsd:vnfd-connection-point-ref: mgmt
nsd:vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2
- nsd:id: f66e6
nsd:vnfd-connection-point-ref:
- nsd:member-vnf-index-ref: '1'
nsd:vnfd-connection-point-ref: east
nsd:vnfd-id-ref: abae3d33-36ec-4707-95aa-e48907bf2442
- nsd:member-vnf-index-ref: '2'
nsd:vnfd-connection-point-ref: east
nsd:vnfd-id-ref: c993c90e-857f-499e-aad3-74f1667216d2

VNF 22 Yaml descriptor

2016-11-30T20:49:52Z

Chamarty: VNF22 Initial descriptor

vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: cp1
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ one VDU
vnfd:id: c993c90e-857f-499e-aad3-74f1667216d2
vnfd:name: Ref_VNF_22
vnfd:short-name: Ref_VNF_22
vnfd:vdu:
- vnfd:external-interface:
- vnfd:name: eth0
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:vnfd-connection-point-ref: cp1
- vnfd:name: iface61
vnfd:virtual-interface:
vnfd:type: PCI-PASSTHROUGH
- vnfd:name: iface62
vnfd:virtual-interface:
vnfd:type: SR-IOV
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm22.qcow2
vnfd:name: Ref_VM6
vnfd:vm-flavor:
vnfd:memory-mb: '1024'
vnfd:storage-gb: '16'
vnfd:vcpu-count: '1'
vnfd:vendor: ETSI
vnfd:version: '1.0'

VNF 12 Yaml descriptor

2016-11-30T20:48:42Z

Chamarty: VNF12 Initial descriptor

vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: mgmt0
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ two VDU
vnfd:id: abae3d33-36ec-4707-95aa-e48907bf2442
vnfd:name: Ref_Vnf_12
vnfd:short-name: Ref_Vnf_12
vnfd:vdu:
- vnfd:description: Middlepoint
vnfd:external-interface:
- vnfd:name: iface30
vnfd:virtual-interface:
vnfd:type: OM-MGMT
vnfd:vnfd-connection-point-ref: mgmt0
vnfd:guest-epa:
vnfd:cpu-pinning-policy: DEDICATED
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm3.qcow2
vnfd:internal-connection-point:
- vnfd:id: 5f813
vnfd:name: icp0
vnfd:type: VPORT
vnfd:internal-interface:
- vnfd:name: iface31
vnfd:vdu-internal-connection-point-ref: 5f813
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:name: Ref_VM3
vnfd:vm-flavor:
vnfd:memory-mb: '2048'
vnfd:storage-gb: '8'
vnfd:vcpu-count: '2'
- vnfd:external-interface:
- vnfd:name: iface42
vnfd:virtual-interface:
vnfd:type: PCI-PASSTHROUGH
- vnfd:name: iface43
vnfd:virtual-interface:
vnfd:type: SR-IOV
vnfd:guest-epa:
vnfd:cpu-pinning-policy: DEDICATED
vnfd:id: e526e
vnfd:internal-connection-point:
- vnfd:id: 9ec35
vnfd:name: icp0
vnfd:type: VPORT
vnfd:internal-interface:
- vnfd:name: iface41
vnfd:vdu-internal-connection-point-ref: 9ec35
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:vendor: ETSI
vnfd:version: '1.0'

NS1 Yaml descriptor

2016-11-30T20:47:28Z

Chamarty: NS1 initial descriptor

nsd:nsd-catalog:
nsd:nsd:
- nsd:constituent-vnfd:
- nsd:member-vnf-index: '1'
nsd:start-by-default: 'true'
nsd:vnfd-id-ref: d6c25720-895a-40a2-b303-b2a98d10674c
- nsd:member-vnf-index: '2'
nsd:vnfd-id-ref: 287671e2-2858-48cf-a13c-b4cb1351aa9f
nsd:description: Reference NS 1
nsd:id: 9b684262-ded5-4d43-82d3-5e2bf69b7446
nsd:name: Ref_NS_1
nsd:vendor: ETSI
nsd:vld:
- nsd:description: Mgmt VL
nsd:id: 54c04
nsd:name: VL1
nsd:short-name: VL1
nsd:type: ELAN
nsd:vendor: ETSI
nsd:vnfd-connection-point-ref:
- nsd:member-vnf-index-ref: '1'
nsd:vnfd-connection-point-ref: mgmt
nsd:vnfd-id-ref: d6c25720-895a-40a2-b303-b2a98d10674c
- nsd:member-vnf-index-ref: '2'
nsd:vnfd-connection-point-ref: mgmt0
nsd:vnfd-id-ref: 287671e2-2858-48cf-a13c-b4cb1351aa9f

VNF 11 Yaml descriptor

2016-11-30T20:46:21Z

Chamarty: VNF11 descriptor

vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: mgmt0
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ VM1 and VM2
vnfd:id: 287671e2-2858-48cf-a13c-b4cb1351aa9f
vnfd:name: Ref_VNF_11
vnfd:short-name: Ref_VNF_11
vnfd:vdu:
- vnfd:external-interface:
- vnfd:name: iface10
vnfd:virtual-interface:
vnfd:type: OM-MGMT
vnfd:vnfd-connection-point-ref: mgmt0
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm1.qcow2
vnfd:name: Ref_VM1
vnfd:vm-flavor:
vnfd:memory-mb: '2048'
vnfd:storage-gb: '8'
vnfd:vcpu-count: '2'
vnfd:vendor: ETSI
vnfd:version: '1.0'

Reference VNF and NS Descriptors (Release ONE)

2016-11-30T20:45:24Z

Chamarty: Added links to child pages

VNF 21 Yaml descriptor

2016-11-30T20:40:00Z

Chamarty: Created page with "vnfd:vnfd-catalog: vnfd:vnfd: - vnfd:connection-point: - vnfd:name: cp1 vnfd:type: VPORT vnfd:description: A simple VNF descriptor w/ o..."

vnfd:vnfd-catalog:
vnfd:vnfd:
- vnfd:connection-point:
- vnfd:name: cp1
vnfd:type: VPORT
vnfd:description: A simple VNF descriptor w/ one VDU
vnfd:id: d6c25720-895a-40a2-b303-b2a98d10674c
vnfd:name: Ref_Vnf_21
vnfd:short-name: Ref_Vnf_21
vnfd:vdu:
- vnfd:external-interface:
- vnfd:name: eth0
vnfd:virtual-interface:
vnfd:type: VIRTIO
vnfd:vnfd-connection-point-ref: cp1
vnfd:id: abd6831e-f811-4580-9aad-1de9c6424180
vnfd:image: ref_vm21.qcow2
vnfd:name: Ref_VM5
vnfd:vm-flavor:
vnfd:memory-mb: '1024'
vnfd:storage-gb: '16'
vnfd:vcpu-count: '1'
vnfd:vendor: ETSI
vnfd:version: '1.0'

Reference VNF and NS Descriptors (Release ONE)

2016-11-30T20:36:50Z

Chamarty:

VNF

2016-11-30T20:28:31Z

Chamarty: Created page with "vnfd:vnfd-catalog: vnfd:vnfd: - vnfd:connection-point: - vnfd:name: cp1 vnfd:type: VPORT vnfd:description: A simple VNF descriptor w/ o..."

Reference VNF and NS Descriptors (Release ONE)

2016-11-30T20:27:20Z

Chamarty:

Reference VNF and NS Descriptors (Release ONE)

2016-11-30T13:17:40Z

Chamarty:

Reference VNF and NS Descriptors (Release ONE)

2016-11-30T13:16:50Z

Chamarty:

File:Ref NS 2.tar.gz

2016-11-30T13:16:00Z

Chamarty: NS descriptor package for Ref_NS2

NS descriptor package for Ref_NS2

File:Ref VNF 22.tar.gz

2016-11-30T13:14:52Z

Chamarty: VNF descriptor package for Ref_VNF_22

VNF descriptor package for Ref_VNF_22

File:Ref VNF 12.tar.gz

2016-11-30T13:14:28Z

Chamarty: VNF descriptor package for Ref_VNF_12

VNF descriptor package for Ref_VNF_12

Reference VNF and NS Descriptors (Release ONE)

2016-11-30T13:10:54Z

Chamarty: Added descriptor packages for Ref VNFs

File:Ref NS1.tar.gz

2016-11-30T13:04:36Z

Chamarty: NS descriptor package for Ref_NS1

NS descriptor package for Ref_NS1

File:Ref VNF 21.tar.gz

2016-11-30T13:03:19Z

Chamarty: Decriptor package for Ref_VNF_21

Decriptor package for Ref_VNF_21

File:Ref VNF 11.tar.gz

2016-11-30T13:02:49Z

Chamarty: VNF descriptor package for Ref_VNF_11

VNF descriptor package for Ref_VNF_11

OSM Release ONE

2016-11-22T20:20:39Z

Chamarty:

Open Source MANO (OSM) is the open source community that aims to deliver 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.

{{#evu:https://www.youtube.com/watch?v=yBWSKwms47E
|alignment=right
}}

__TOC__

=Interaction with VIMs and VNFs=
The following figure shows OSM interaction with VIM and VNFs.

[[File:OSMconnectivity1.png|400px|OSM Release 1 connectivity 1]]

In simpler setups, OSM only requires a single interface as long as both VIM and VNF IP addresses are reachable

[[File:OSMconnectivity2.png|400px|OSM Release 1 connectivity 2]]

=Install OSM=

==Install from source==

All you need to run OSM Release One is a single server or VM with the following requirements:
* 8 CPUs, 16 GB RAM, 100GB disk and a single interface with Internet access
* Ubuntu16.04 as base image (http://releases.ubuntu.com/16.04/), configured to run LXD containers. If you don't have LXD configured, you can follow the instructions here ([[LXD configuration for OSM release 1|LXD configuration]])

Once you have prepared the host with the previous requirements, all you need to do is:
wget https://osm-download.etsi.org/ftp/osm-1.0-one/install_from_source.sh
chmod +x install_from_source.sh
./install_from_source.sh

After some time, you will get a fresh OSM Release One installation. You can access to the UI in the following URL (user:admin, password: admin):

You can connect to the service via a web browser (Google Chrome version 50 or later is recommended). Open a browser and connect to https://1.2.3.4:8443 , replacing 1.2.3.4 with the IP address of your host. Note that it uses https, not http.
We recommend using Google Chrome when connecting to an SSL enabled Launchpad.
If you are using Firefox and plan to use the self-signed certificate provided in the installation, please follow instructions at [http://open.riftio.com/documentation/riftware/4.3/a/monitor/avoiding-selfsigned-certificate-warnings.htm#Using2 Using untrusted, self-signed certificates]
Alternatively, you can run Launchpad with trusted CA signed SSL certs as per [http://open.riftio.com/documentation/riftware/4.3/a/monitor/avoiding-selfsigned-certificate-warnings.htm#Using Using a certificate signed by a trusted CA]
or, run Launchpad with SSL disabled as per [http://open.riftio.com/documentation/riftware/4.3/a/user-guide/run-launchpad-with-ssl-disabled.htm?Highlight=disable Run Launchpad with SSL Disabled]

[[File:OSMloginWindow.png|400px|OSM login window]]

Make sure that port 8443 is accessible, as well as the following required ports: 8000, 4567, 8008, 80, 9090.

As a result of the installation, three LXD containers are created in the host: RO, VCA, and SO-ub (running the SO and the UI), as shown in the figure below.

[[File:OSMcontainers.png|400px|OSM Release ONE installation result]]

=Adding a VIM account=
Before proceeding, make sure that you have a site with a VIM configured to run with OSM. Three different kinds of VIMs are currently supported by OSM:
*OpenVIM. Check the following link to know how to install and use openvim for OSM: [[OpenVIM installation (Release One)]]
*OpenStack. Check the following link to learn how to configure OpenStack to be used by OSM: [[Openstack configuration (Release ONE)]]
*VMware vCloud Director. Check the following link to learn how to configure VMware VCD to be used by OSM: [[Configuring VMware vCloud Director for OSM Release One]]

==OpenVIM site==
*Go into the RO container:
lxc exec RO -- bash
*Execute the following commands, using the appropriate parameters (e.g. site name: "openvim-site", IP address: 10.10.10.10, VIM tenant: "osm")
export OPENMANO_TENANT=osm
openmano datacenter-create openvim-site http://10.10.10.10:9080/openvim --type openvim --description "Openvim site"
openmano datacenter-attach openvim-site --vim-tenant-name=osm
openmano datacenter-list
exit #or Ctrl+D to get out of the RO container

==Openstack site==
*Go into the RO container:
lxc exec RO -- bash
*Execute the following commands, using the appropriate parameters (e.g. site name: "openstack-site", IP address: 10.10.10.11, VIM tenant: "admin", user: "admin", password: "userpwd")
export OPENMANO_TENANT=osm
openmano datacenter-create openstack-site http://10.10.10.11:5000/v2.0 --type openstack --description "OpenStack site"
openmano datacenter-attach openstack-site --user=admin --password=userpwd --vim-tenant-name=admin
openmano datacenter-list
exit #or Ctrl+D to get out of the RO container

==VMware site==
*Go into the RO container:
lxc exec RO -- bash
*Execute the following commands, using the appropriate parameters (e.g. site name: "vmware-site", IP address: 10.10.10.12, VIM tenant: "vmware-tenant", user: "osm", password: "osm4u", admin user: "admin", admin password: "adminpwd")
openmano datacenter-create vmware-site https://10.10.10.12 --type vmware --description "VMware site" --config '{admin_password: adminpwd, admin_username: admin}'
openmano datacenter-attach vmware-site --user=osm --password=osm4u --vim-tenant-name=vmware-tenant
openmano datacenter-list
exit #or Ctrl+D to get out of the RO container

Note: The name of the site/datacenter "vmware-site" has to match the name of the organization of "vCloud Director". Inside this organization the tenant "vmware-tenant" must exist

=Deploying your first Network Service=
In this example we will deploy the following Network Service, consisting of two simple VNFs based on CirrOS connected by a simple VLD.

[[File:cirros_2vnf_ns.png|500px|NS with 2 CirrOS VNF]]

Before going on, download the required VNF and NS packages from this URL: https://osm-download.etsi.org/ftp/examples/cirros_2vnf_ns/

==Uploading VNF image to the VIM==
Get the cirros 0.3.4 image from the following link: http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img

Then, onboard the image into the VIM. The instruction differs from one VIM to another:
*In Openstack:
openstack image create --file="./cirros-0.3.4-x86_64-disk.img" --container-format=bare --disk-format=qcow2 --public --property location="/mnt/powervault/virtualization/osm/CirrOS/cirros-0.3.4-x86_64-disk.img" cirros034
*In openvim:
openvim image-create --name cirros034 --path /mnt/powervault/virtualization/osm/CirrOS/cirros-0.3.4-x86_64-disk.img

==Onboarding a VNF==
*From the UI:
**Go to Catalog
**Click on the import button, then VNFD
**Drag and drop the VNF package file cirros_vnf.tar.gz in the importing area.
[[File:onboardingVNF.png|300px|Onboarding a VNF]]
*From the SO CLI:

Execute the following from the SO-ub container("lxc exec SO-ub bash"):

/root/SO/rwlaunchpad/plugins/rwlaunchpadtasklet/scripts/onboard_pkg -s 127.0.0.1 -u <vnf-package-name>

==Onboarding a NS==
*From the UI:
**Go to Catalog
**Click on the import button, then NSD
**Drag and drop the NS package file cirros_2vnf_ns.tar.gz in the importing area.
*From the SO CLI:

From the SO-ub container execute the following command("lxc exec SO-ub bash")
/root/SO/rwlaunchpad/plugins/rwlaunchpadtasklet/scripts/onboard_pkg -s 127.0.0.1 -u <ns-package-name>

==Instantiating the NS==
*From the UI:
**Go to Launchpad > Instantiate
**Select the NS descriptor to be instantiated, and click on Next
**Add a name to the NS instance, and click on Launch.
[[File:instantiatingNS.png|300px|Instantiating a NS (step 1)]] [[File:instantiatingNS-step2.png|400px|Instantiating a NS (step 2)]]
*From the SO CLI:

From the SO-ub container execute the following command ("lxc exec SO-ub bash")

/root/SO/rwlaunchpad/plugins/rwlaunchpadtasklet/scripts/onboard_pkg -i <ns-instance-name> -d <nsd-id> -D <data-center-id>

Wait for the message that the NS has been successfully deployed, and that's all!

== Accessing CLI for viewing instantiated NS details ==

From the SO-ub container execute the following command ("lxc exec SO-ub bash") to bring up SO CLI(username:admin password:admin)

/usr/rift/rift-shell -r -i /usr/rift -a /usr/rift/.artifacts -- rwcli --rift_var_root /usr/rift/var/rift

The CLI can be used to both configure the system and show operational-data from the system.

Example CLIs,

rift# show nsd-catalog # show the nsd catalog
rift# show vnfd-catalog # show vnfd catalog
rift# show ns-instance-config nsr # Lists instantiated network service
rift# show ns-instance-opdata nsr # Lists of instantiated network service op-data

=Additional information=

*Check other VNF packages and NS packages in the links below:
**VNF packages: https://osm-download.etsi.org/ftp/osm-1.0-one/vnf-packages
**NS packages: https://osm-download.etsi.org/ftp/osm-1.0-one/ns-packages
*[[Deploying advanced Network Services (Release ONE)|Deploy advanced Network Services]]
*[[Creating your own VNF package (Release ONE)|Create your own VNF package]]
*[[How to report issues (Release ONE)|Have you detected any bug? Check this guide to see how to report issues]]
*[[Logs and troubleshooting (Release ONE)|Logs and troubleshooting]]
*[[Release ONE Data Model details|Data Model Details]]
*[https://osm.etsi.org/images/OSM-Whitepaper-TechContent-ReleaseONE-FINAL.pdf OSM White Paper - Release ONE Technical Overview]
*[[Release ONE Technical FAQ|Technical FAQ]]

{{Feedback}}

Logs and troubleshooting (Release ONE)

2016-11-22T12:33:58Z

Chamarty: Changed "SO bash" to "SO-ub bash"

'''Under elaboration'''

__TOC__

=Logs=
==UI logs==

The server-side UI logs can be obtained on the SO-ub container at:
<pre>
/usr/rift/usr/share/rw.ui/skyquake/err.log
/usr/rift/usr/share/rw.ui/skyquake/out.log
</pre>

Client side UI logs can be obtained in the Developer Console in a browser.

==SO logs==

SO logs can be obtained on the SO-ub container at:
<pre>
/var/log/rift/rift.log
</pre>

==RO logs==
RO logs can be obtained on the RO container at:
<pre>/var/log/openmano/openmano.log</pre>

Log file and log level (''debug'' by default) can be set at file:
<pre>/etc/default/openmanod.cfg</pre>

==VCA logs==

=Troubleshooting=

==Troubleshooting UI==

===UI status===
* The status of the UI process can be checked by running the following command in the SO-ub container as root:
<pre>
forever list
</pre>
* You should see a status similar to following with an uptime:
<pre>
info: Forever processes running
data: uid command script forever pid id logfile uptime
data: [0] uivz /usr/bin/nodejs skyquake.js --enable-https --keyfile-path=/usr/rift/etc/ssl/current.key --certfile-path=/usr/rift/etc/ssl/current.cert 21071 21082 /root/.forever/forever.log 0:18:12:3.231
</pre>
* In case the UI server process has issues, you won't see an uptime but will instead see a status "STOPPED" in that position.
* In case the UI server process never started, you'll see a status saying "No forever processes running".

===Restarting UI===
* The UI is restarted when the SO module (launchpad) is restarted.
* However, in case just the UI needs to be restarted, you can run the following command in the SO-ub container as root:
<pre>
forever restartall
</pre>

===Known error messages in the UI and their solution===

==Troubleshooting SO==

===SO status===

===Restarting SO===
To restart SO module, please follow the following instructions
lxc restart SO-ub # Optional, Needed if there is an existing running instance of launchpad
lxc exec SO-ub -- nohup sudo -b -H /usr/rift/rift-shell -r -i /usr/rift -a /usr/rift/.artifacts -- ./demos/launchpad.py --use-xml-mode

===Known error messages in the SO and their solution===

==Troubleshooting RO==

===RO status===
The status of the RO process can be checked by running the following command in the RO container as root:
<pre>
service openmano status
● openmano.service - openmano server
Loaded: loaded (/etc/systemd/system/openmano.service; disabled; vendor preset: enabled)
Active: active (running) since Wed 2016-11-02 16:50:21 UTC; 2s ago
Main PID: 550 (python)
Tasks: 1
Memory: 51.2M
CPU: 717ms
CGroup: /system.slice/openmano.service
└─550 python /opt/openmano/openmanod.py -c /opt/openmano/openmanod.cfg --log-file=/opt/openmano/logs/openmano.log

Nov 02 16:50:21 RO-integration systemd[1]: Started openmano server.
</pre>

In case it is not running, try to see the last logs at '''/var/log/openmano/openmano.log'''

===Restarting RO===
RO can be restarted on the RO container at:
<pre>service openmano restart</pre>

===Known error messages in the RO and their solution===
Possible known errors are:

====Invalid openstack credentials====

SYMPTOM: At deployment it appears the error message: Not possible to get_networks_list from VIM: AuthorizationFailure: Authorization Failed: The resource could not be found. (HTTPS: 404)

CAUSE: Openstack is not properly added to openmano with the right credentials

SOLUTION: See the steps at [[OSM_Release_ONE#Openstack_site]]. If the problem persist ensure openstack is properly configured. Ensure you have access to the openstack endpoints (many times port 5000 is redirected using iptables, but other endpoints use other ports that must also be redirected). Can be checked using openstack client with:
sudo apt install python-openstackclient
openstack --os-project-id <auth-project-id> --os-url <auth-url> --os-username <auth-username> --os-password <auth-password> --debug network list #server list
#providing the same URL, credentials as you provide to openmano. The (--debug) will show more info so that you will see the IP/ports it try to access

====Wrong database version====

SYMPTOM: openmano service fails. At openmano logs appear:
<pre>2016-11-02T17:19:51 CRITICAL openmano openmanod.py:268 DATABASE wrong version '0.15'. Try to upgrade/downgrade to version '0.16' with './database_utils/migrate_mano_db.sh'</pre>

CAUSE: Openmano has been upgraded with a new version that requieres a new database version.

SOLUTION: To upgrade de database version run ./database_utils/migrate_mano_db.sh and provide credentias if needed (by default database user is 'mano', and database password is 'manopw')

==Troubleshooting VCA==

===VCA status===

===Restarting VCA===

===Known error messages in the VCA and their solution===

=Software upgrade=
OSM is being upgraded periodically to fix bugs that are being reported. Last version curresponds with the tag v1.0.1. These guidelines show you how to upgrade the different components.

==UI upgrade==

'''Note:''' It is recommended to upgrade both SO and UI modules together.

Execute at UI container ("lxc exec SO-ub bash" to enter into the container, "exit" to exit)

cd /root/UI
git pull --rebase
git checkout tags/v1.0.1
make clean && make -j16 && make install

Follow [[Logs_and_troubleshooting_(Release_ONE)#Software_upgrade#SO_upgrade|SO upgrade]] to upgrade SO and restart launchpad.

==SO upgrade==

Execute at SO container ("lxc exec SO-ub bash" to enter into the container, "exit" to exit)

cd /root/SO
git pull --rebase
git checkout tags/v1.0.1
make clean && make -j16 && make install

Exit from SO-container and restart SO-ub container and Launchpad

lxc restart SO-ub
lxc exec SO-ub -- nohup sudo -b -H /usr/rift/rift-shell -r -i /usr/rift -a /usr/rift/.artifacts -- ./demos/launchpad.py --use-xml-mode

==RO upgrade==

Execute at RO container ("lxc exec RO bash" to enter into the container, "exit" to exit)

service openmano stop
git -C /opt/openmano pull --rebase
git -C /opt/openmano checkout tags/v1.0.1
/opt/openmano/database_utils/migrate_mano_db.sh
service openmano start

==VCA upgrade==