Apex an installation tool deploys according to OPNFV requirements standards using RDO Manager from the RDO Project. This document will describe the process to build Apex and to integrate new features into Apex.

To get a good overview of the terms that describe an Apex deployment and the target architecture of what is deployed please review the Installation Instructions. Apex Installation Instructions

There are a collection of files executed during build that are helpful to understand. Not all files used in build are listed here, these are the primary files.

Apex is built in a few stages and tasks summarized here:

• construct virtual machine and dump their definitions
• attach to RDO Project repository
• download disk images
• modify downloaded disk images
• build RPM with configuration, scripts and disk images
• build CentOS ISO for offline deployment

Building Apex is as simple as cloning the git repository and executing the build. The build scripts are designed to ensure that all the software dependencies are made available to the build. There are a few requirements to consider before building.

• password-less tty-less sudo or root access is required
• properly working libvirt installation is required
• a new user will be autocreated named stack (this is for awareness only, no action required)
• disk images, a centos iso, the Apex RPMs and iso and a build cache will all be written to disk which average around 80G of space at the time of this doc being written.

Steps to build:

$ git clone https://gerrit.opnfv.org/gerrit/p/apex.git
$ cd apex/ci
$ ./build -v {build-version} -c file:///{cache-storage-location}

{build-version} is an RPM release number compatible identifier. This is used in both the RPM release value and to name the ISO.
{cache-storage-location} is where the 7-10G cache file will be stored between builds

To build Apex, artifacts and packages are collected from the RDO Project build system. This includes:

• RPM Packages from the RDO Release Repository
• A pre-built Undercloud qcow2 image
• Pre-built introspection images
• Pre-built Overcloud qcow2 image

The disk images are cached after build so that they don't have to be downloaded again if they haven't been refreshed upstream. Though, RDO Project can rebuild them as frequently as every 8 hours. Once these disk images are downloaded the build process will modify them in preparation to use for Apex deployment.

Apex will also collect and prepare the artifacts for the SDN controller options that are supported for deployment.

Next, a collection of virtual machines are constructed:

• the Instack Undercloud VM
• 5 "Baremetal VMs" that the overcloud is deployed to in a virtual deployment.

Finally, the VM definitions are dumped to disk in preparation for packaging

Once instack.sh has run and has dumped all the files to disk that are needed to build, git archive is run which generates the initial tarball the RPM will build from. During build, files are generated that need to be included in the tarball so that the RPM has access to them for packaging. The tarball is appended with the necessary files for final packaging and deployment. Rpmbuild is executed to roll the RPM that includes the configuration files, deployment scripts and disk images necessary for deployment.

Once the RPM is built the CentOS installation DVD is downloaded, exploded, modified adding the Apex RPM and updating the installation configuration files for the OS and the ISO is rebuilt with the updated contents.

RDO Manager from the RDO Project is the OpenStack installation platform that Apex is built on. Patches submitted must fit 1 of 2 criteria in order to be submitted for merge:

1. update the Apex and or OPNFV specific contents of the project
2. intent to update an upstream project used by Apex
   1. patches for upstream projects can be carried temporarily in the Apex code base as long as there is active effort for the patch to be merged into the upstream project.

In addition, the RDO Manager project itself is considered "midstream" and it's upstream counterpart is called TripleO (also called "ooo").

In order to integrate your feature into Apex, you must create a patch for TripleO code. TripleO uses heat templates with puppet configuration providers as its method to configure OpenStack Controllers and Images. The TripleO sub-project for this is called "tripleo-heat-templates".

As previously mentioned we can accodomate applying that patch via the Apex project, until the code is merged upstream. At the time of this writing we currently do this for the OpenDaylight Controller feature. An example commit for tripleo-heat-templates providing OpenDaylight installation can be found here tripleO-OpenDaylight. They key files to modify include the yaml based heat templates, as well as the puppet modules.

Key Heat Templates:

• puppet/controller.yaml (Controller Heat resource definition)
• puppet/compute.yaml (Compute Heat resource definition)
• overcloud.yaml (Overall Role definitions, previously called overcloud-without-merge in stable/liberty)

Key Puppet Modules:

• puppet/manifests/overcloud_compute.pp (Compute puppet module)
• puppet/manifests/overcloud_controller.pp (Controller puppet module for no-HA)
• puppet/manifests/overcloud_controller_pacemaker.pp (Controller puppe tmodule for HA)

Document is work in progress. More content is on its way