Technical FAQ (Release THREE): Difference between revisions

From OSM Public Wiki
Jump to: navigation, search
m (Garciadeblas moved page Release TWO Technical FAQ to Technical FAQ)
No edit summary
Line 1: Line 1:
== Connection error: not possible to contact OPENMANO-SERVER (openmanod) ==
'''Q'''. After following the steps carefully as stated in [[OSM Release TWO]] web page, I tried to instantiate the Network Service. All seems correct until the last phase, when I get an error in the UI. I connected to the SO-ub container, opened the SO CLI and run commands below:
'''Q'''. After following the steps carefully as stated in [[OSM Release TWO]] web page, I tried to instantiate the Network Service. All seems correct until the last phase, when I get an error in the UI. I connected to the SO-ub container, opened the SO CLI and run commands below:
  $ lxc exec SO-ub -- bash
  $ lxc exec SO-ub -- bash
Line 12: Line 15:


----
----
== "Instantiation failed" without additional information ==


'''Q'''. After trying to instantiate, I got the message that the instantiation failed without much information about the reason.
'''Q'''. After trying to instantiate, I got the message that the instantiation failed without much information about the reason.

Revision as of 15:58, 16 May 2017

Connection error: not possible to contact OPENMANO-SERVER (openmanod)

Q. After following the steps carefully as stated in OSM Release TWO web page, I tried to instantiate the Network Service. All seems correct until the last phase, when I get an error in the UI. I connected to the SO-ub container, opened the SO CLI and run commands below:

$ lxc exec SO-ub -- bash
root@SO-ub:~# /usr/rift/rift-shell -r -i /usr/rift -a /usr/rift/.artifacts -- rwcli --rift_var_root /usr/rift/var/rift       (user: admin; pwd: admin)
rift# show ns-instance-opdata nsr

The last command allows getting a more comprehensive view about what it is happening. In the last operational-events field, namely "ns-field", details say: "Connection error: not possible to contact OPENMANO-SERVER (openmanod)". I do not know how to fix the problem. I have checked all the previous steps and they seem they are correct.

A. First, please check connectivity to RO container. Can you ping the RO IP address (configured in SO) from SO-ub container? If not, then make sure that osm-ro service is up and running on the RO container.

$ lxc exec RO -- bash
root@SO-ub:~# service osm-ro status
root@SO-ub:~# OPENMANO_TENANT=osm openmano datacenter-list

"Instantiation failed" without additional information

Q. After trying to instantiate, I got the message that the instantiation failed without much information about the reason.

A. Typically you will be hitting a timeout issue in the SO. Although we are working in providing better feedback, below you can find a detailed explanation.

During instantiation, two timeouts can expire:

  • SO-RO timeout, caused because the creation of VMs and networks from the RO to the VIMs takes too long. In some cases, all VMs and networks are created in the VIM; however, the instantiation might still reach an SO-RO timeout if not all VNFs have a management IP address.
  • SO-VCA timeout, caused because the VNF configuration via Juju charms takes too long.

Recommendations:

  • Check SO logs, specifically "rift.log" to find out what timeout you might be hitting.
  • In case of a SO-VCA timeout, connect to VCA container and check "juju status".
  • In case of a SO-RO timeout, check in the VIM if the VMs and networks were created. If they were created at the VIM, you might still get a failed NS instantiation due to a SO-RO timeout if VNFs do not get an IP address in the management interface. In that case, check below.

Q. After trying to instantiate, I got the message that the instantiation failed without much information about the reason. After checking the logs, it seems to be a timeout issue. However, I am seeing that the VMs and networks were created at the VIM.

A. Even when the VMs and networks were created at the VIM, you might still get a failed NS instantiation due to a SO-RO timeout if VNFs do not get an IP address in the management interface.

The management interface is indicated in the VNF Descriptors. For instance, you can check the Cirros VNFD here. The following two fields are relevant:

  • vnfd:mgmt-interface:vdu-id: indicates which VDU (which of the VMs) will be checked to know if the VNF has a management IP address.
  • vnfd:vdu:external-interface:virtual-interface: if the interface type is “OM-MGMT”, then this is the management interface that will be checked to know if the VDU has IP address.

The way how management IP addresses are assigned to the VNFs change from one VIM to another. In all the cases, the recommendation is the following: pre-provision a management network in the VIM, with DHCP enabled. You can see, for instance, the instructions in the case of Openstack (https://osm.etsi.org/wikipub/index.php/Openstack_configuration_(Release_TWO) ).