Prerequisites for Openstack
Installing ONAP in vanilla OpenStack from command line is very similar to installing ONAP in Rackspace (see Tutorial: Configuring and Starting Up the Base ONAP Stack). The Heat templates that install ONAP in Rackspace and vanilla OpenStack are similar too. The main difference is the way resource-intensive VMs are defined. Unlike OpenStack, Rackspace requires to explicitly create a local disk for memory- or CPU-intensive VMs.
Currently, there are three different Heat templates for ONAP installation in vanilla OpenStack:
ALL TEMPLATES ABOVE SUPPORT DCAE DATA COLLECTION AND ANALYTICS PLATFORM INSTALLATION. In onap_openstack.yaml / onap_openstack.env and onap_openstack_float.yaml / onap_openstack_float.env you are required to manually allocate five (5) Floating IP addresses to your OpenStack project. To allocate those addresses, from the OpenStack horizon dashboard, click on Compute -> Access & Security -> Floating IPs. Then click “Allocate IP To Project” five times. OpenStack will assign five IPs to your project. Then, please assign the allocated Floating IPs to the following VMs defined in the Heat environment file:
dcae_coll_float_ip
dcae_hdp1_float_ip
dcae_hdp2_float_ip
dcae_hdp3_float_ip
dcae_db_float_ip
At run time, the DCAE controller will fetch those IPs from the underlying OpenStack platform and assign them to the VMs defined above. The "dcae_base_environment" parameter is set to 1-NIC-FLOATING-IPS.
For onap_openstack_nofloat.yaml / onap_openstack_nofloat.env no floating IP address allocation is required. OpenStack will assign public addresses to the DCAE VMs based on availability. In onap_openstack_nofloat.env, the "dcae_base_environment" parameter is set to 2-NIC.
Note that the DCAE controller handles only one set of IP addresses, either floating IPs or private IPs. As such, in the onap_openstack.yaml and onap_openstack_float.yaml templates, which use floating IPs, the private IP addresses assigned to the five additional VMs that DCAE creates off the Heat template will not be considered. OpenStack will assign them five private IPs in the Private Management Network based on availability. More details about DCAE setup available here: DCAE Controller Development Guide.
The figure below shows the network setup created with onap_openstack_float.yaml / onap_openstack_float.env. As described above, ONAP VMs have a private IP address in the ONAP Private Management Network space and use floating IP addresses for remote access and connection to Gerrit and Nexus repositories. A router that connects the ONAP Private Management Network to the external network is also created.
In this section, we describe the structure of onap_openstack_float.yaml, which assigns fixed floating IPs to ONAP VMs. However, because the different Heat templates have a similar structure (except for the network setup), the same considerations apply also to onap_openstack.yaml and onap_openstack_nofloat.yaml.
The Heat template contains the parameters and resources (i.e. vCPUs, vNICs, RAM, local and external volumes, ...) necessary to build ONAP components. After ONAP VMs have been created, a post-instantiation bash script that installs software dependencies is ran in any VM. In release 1.0.0, this script was part of the Heat template. Since release 1.1.0, the bash script has been simplified: it only contains the operations necessary to pass configuration parameters to a VM, while the logic that downloads software dependencies and sets the execution environment up has been moved off to a new bash script that is downloaded from Nexus.
The rationale behind this change is that ONAP will need to support multiple platforms (currently it supports Rackspace and vanilla OpenStack), which may require different Heat templates, while a VM installation script will remain unchanged. This will avoid to change a script multiple times, once for each Heat template.
Find below an example of the simplified post-instantiation bash script for MSO, with the list of all the configuration parameters passed to the VM and available in /opt/config:
The post-instantiation bash script downloads (from Nexus) and runs an install script, mso_install.sh in the example above, which installs software dependencies like Git, Java, NTP daemon, docker-engine, docker-compose, etc. Finally, the install script downloads (from Nexus) and runs an init script, e.g. mso_vm_init.sh, which downloads and runs docker images. The rationale of having two bash scripts is that the install script runs only once, after a VM is created, while the init script runs after every VM (re)boot to pickup the latest changes in Gerrit and download and run the latest docker image for a specific ONAP component.
In order to correctly install ONAP in vanilla OpenStack, it is necessary to set the following parameters in the Heat environment file, based on the specific OpenStack environment:
Note:
A&AI now has two (2) instances. One has the docker containers that run the A&AI logic and one has databases and third-party software dependencies.
$ glance image-list | grep buntu
| c60d00b6-d03e-492b-9eed-e6580b438619 | Ubuntu_16.04_xenial |
$ openstack flavor list | grep onap
| 123 | onap_small | 4192 | 0 | 0 | 1 | True |
| 124 | onap_medium | 8192 | 0 | 0 | 1 | True |
| 125 | onap_large | 8192 | 0 | 0 | 2 | True |
| 126 | onap_xlarge | 16192 | 0 | 0 | 2 | True |
$ openstack floating ip list
+--------------------------------------+---------------------+------------------+------+--------------------------------------+----------------------------------+
| ID | Floating IP Address | Fixed IP Address | Port | Floating Network | Project |
+--------------------------------------+---------------------+------------------+------+--------------------------------------+----------------------------------+
| 03fffffff0-07f5-4172-a71d-fb1394e1f7b4 | 44.253.254.255 | None | None | fffffff-59f0-415c-880d-d05ec86ff8f0 | fffffc6575bda4525b49433a38e697e22 | etc...
$ openstack network list | grep public
| b4f41afd-1f08-47f8-851b-ca536bffffff | public | d4902035-2d4c-40cc-8a05-e916401fffff |
Note:
Be careful not to use private address space 172.18.0.0/16 for the setup of vanilla opernstack and/or the provider network and the floating addresses therein.
Some containers create a route in the hosting VM form 172.18.0.0./16 to a br-<some-hex-string> bridge which means these containers cannot connect to any other VM and/or container in the 172.18.0.0/16 space. DCAE might be the most prominent victim for that. See also Undocumented network 172.18.0.0/16 in some ONAP VMs - can it be re-configured in https://wiki.onap.org/questions
Note:
Neutron may require that the dns_nameservers property of a OS::Neutron::Subnet resource be explicitly set, in order to allow VMs in the subnet to access the external network. dns_nameservers is a list of DNS IP addresses. However, some OpenStack installations do not support lists is the "user_data" section of a Heat template, which is used to build configuration files that are used during ONAP installation. As such, we define two different parameters: 1) dns_list is a list of DNS IP addresses that is provided to Neutron; 2) external_dns is a string that contains one of the DNS IP addresses in the list and can be used in the "user_data" section. In many cases, when only one DNS address is provided, these two parameters will be set to the same value.
All the other parameters in the environment file are set and can be left untouched.
Note that the IP addresses in the ONAP Private Management Network are also set, but they can be changed at will, still making sure that they are consistent with the private network CIDR.
Finally, the Heat environment file contains some DCAE-specific parameters. Some of them are worth mentioning:
dcae_base_environment specifies the DCAE networking configuration and shouldn't be modified (see above for a description of the DCAE network configuration, i.e. 1-NIC-FLOATING-IPS vs. 2-NIC). openstack_region must reflect the OpenStack OS_REGION_NAME environment variable (please refer to Tutorial: Configuring and Starting Up the Base ONAP Stack for cloud environment variables), while dcae_zone and dcae_state can contain any meaningful location information that helps the user distinguish between different DCAE deployments. For example, if an instance of DCAE is deployed in a data center in New York City, the two parameters can assume the following values:
As some ONAP components still currently use v2 Keystone API you should have both, v2 and v3 configured in your environment. That means to have endpoints url without any version at the end.
If you have already installed keystone identity component and created endpoints, you can modify them directly in Maria DB. To do this, run the following commands in red (id should refer to the 3 endpoints, internal, public and admin you have created):
