Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Currently, there are three different Heat templates for ONAP installation in vanilla OpenStack:

  • 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. CURRENTLY, THIS TEMPLATE DOES NOT SUPPORT DCAE DATA COLLECTION AND ANALYTICS PLATFORM INSTALLATION.
  • 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 releasesTHIS TEMPLATE SUPPORTS DCAE DATA COLLECTION AND ANALYTICS PLATFORM INSTALLATION. In order to correctly install the Data Collection and Analytics Platform, at this time, the DCAE controller requires manual allocation of 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 you. Then, please assign these 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 to the VMs defined above.

  • 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. CURRENTLY, THIS TEMPLATE DOES NOT SUPPORT DCAE DATA COLLECTION AND ANALYTICS PLATFORM INSTALLATION.


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.

...

  • 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
  • dns_list: 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)
  • external_dns: PUT THE FIRST ADDRESS OF THE EXTERNAL DNS LIST HERE
  • aai1_float_ip: PUT A&AI INSTANCE 1 FLOATING IP HERE
  • aaiaai2_float_ip: PUT A&AI FLOATING INSTANCE 2 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:

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.


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

...

  • oam_network_cidr: 10.0.0.0/8
  • aaiaai1_ip_addr: 10.0.1.1
  • aai2_ip_addr: 10.0.1.2
  • 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_base_environment: LEFT FOR FUTURE DCAE RELEASES 1-NIC-FLOATING-IPS
  • dcae_zone, dcae_state: The location in which DCAE is deployed
  • openstack_region: The OpenStack Region in which DCAE is deployed (also used by MSO)

dcae_base_environment specifies the DCAE networking configuration and shouldn't be modified. 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:

...