Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Overview

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 below, 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

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.

Heat Environment File

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:

  • public_net_id: PUT YOUR NETWORK ID/NAME HERE
  • ubuntu_1404_image: PUT THE UBUNTU 14.04 IMAGE NAME HERE
  • ubuntu_1604_image: PUT THE UBUNTU 16.04 IMAGE NAME HERE
  • flavor_small: PUT THE SMALL FLAVOR NAME HERE
  • flavor_medium: PUT THE MEDIUM FLAVOR NAME HERE
  • flavor_large: PUT THE LARGE FLAVOR NAME HERE
  • flavor_xlarge: PUT THE XLARGE FLAVOR NAME HERE
  • pub_key: PUT YOUR PUBLIC KEY HERE
  • openstack_tenant_id: PUT YOUR OPENSTACK PROJECT ID HERE
  • openstack_username: PUT YOUR OPENSTACK USERNAME HERE
  • openstack_api_key: PUT YOUR OPENSTACK PASSWORD HERE
  • horizon_url: PUT THE HORIZON URL HERE
  • keystone_url: PUT THE KEYSTONE URL HERE
  • external_dns: PUT THE ADDRESS OF THE EXTERNAL DNS HERE (e.g. a comma-separated list of IP addresses in your /etc/resolv.conf in UNIX-based Operating Systems)
  • aai_float_ip: PUT A&AI FLOATING IP HERE
  • appc_float_ip: PUT APP-C FLOATING IP HERE
  • dcae_float_ip: PUT DCAE FLOATING IP HERE
  • dcae_coll_float_ip: PUT DCAE COLLECTOR FLOATING IP HERE
  • dcae_db_float_ip: PUT DCAE DATABASE FLOATING IP HERE
  • dcae_hdp1_float_ip: PUT DCAE HADOOP VM1 FLOATING IP HERE
  • dcae_hdp2_float_ip: PUT DCAE HADOOP VM2 FLOATING IP HERE
  • dcae_hdp3_float_ip: PUT DCAE HADOOP VM3 FLOATING IP HERE
  • dns_float_ip: PUT DNS FLOATING IP HERE
  • mso_float_ip: PUT MSO FLOATING IP HERE
  • mr_float_ip: PUT MESSAGE ROUTER FLOATING IP HERE
  • policy_float_ip: PUT POLICY FLOATING IP HERE
  • portal_float_ip: PUT PORTAL FLOATING IP HERE
  • robot_float_ip: PUT ROBOT FLOATING IP HERE
  • sdc_float_ip: PUT SDC FLOATING IP HERE
  • sdnc_float_ip: PUT SDN-C FLOATING IP HERE
  • vid_float_ip: PUT VID FLOATING IP HERE

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 3246457 in https://wiki.onap.org/questions


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.

  • oam_network_cidr: 10.0.0.0/8
  • aai_ip_addr: 10.0.1.1
  • appc_ip_addr: 10.0.2.1
  • dcae_ip_addr: 10.0.4.1
  • dns_ip_addr: 10.0.100.1
  • mso_ip_addr: 10.0.5.1
  • mr_ip_addr: 10.0.11.1
  • policy_ip_addr: 10.0.6.1
  • portal_ip_addr: 10.0.9.1
  • robot_ip_addr: 10.0.10.1
  • sdc_ip_addr: 10.0.3.1
  • sdnc_ip_addr: 10.0.7.1
  • vid_ip_addr: 10.0.8.1

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

  • dcae_zone, dcae_state: The location in which DCAE is deployed
  • openstack_region: The OpenStack Region in which DCAE is deployed

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:

  • dcae_zone: nyc01
  • dcae_state: ny


  • No labels