...

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.

The Heat template for vanilla OpenStack replicates typical application deployments in OpenStack. As shown in the figure belowCurrently, there are three different Heat templates for ONAP installation in vanilla OpenStack:

1. onap_openstack.yaml / onap_openstack.env: ONAP VMs created out of this template have one vNIC. The vNIC has a private IP towards the Private Management Network and a floating IP. The floating IPs addresses are assigned during ONAP installation by OpenStack, based on floating IP availability. This template can be used when users do not know the set of floating IPs assigned to them. Note that this template should be used in OpenStack Kilo and older releases, because those releases do not support fixed floating IP association via Heat template.
2. onap_openstack_float.yaml / onap_openstack_float.env: ONAP VMs created out of this template have one vNIC. The vNIC has a private IP towards the Private Management Network and a floating IP. The floating IPs addresses are specified ahead of time in the environment file. This template can be used when users always want to assign the same floating IP to an ONAP VM in different ONAP installation. Note that fixed floating IP assignment via Heat template is not supported in OpenStack Kilo and older releases.
3. onap_openstack_nofloat.yaml / onap_openstack_nofloat.env: ONAP VMs created out of this template have two vNICs: one has a private IP towards the Private Management Network and the other one has a public IP address towards the external network. From a network resource perspective, this template is similar to the Heat template used to build ONAP in Rackspace.

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.

Heat Template

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.

...

Finally, the Heat environment file contains some DCAE-specific parameters. Some of them are worth mentioning:

• dcae_base_environment: LEFT FOR FUTURE DCAE RELEASES
• dcae_zone, dcae_state: The location in which DCAE is deployed
• openstack_region: The OpenStack Region in which DCAE is deployed

...