Basic Deployment (CLI)¶

Prepare Your Environment¶

1. Make sure you have your environment ready and undercloud running:

   • Environment Setup
   • Installing the Undercloud

2. Log into your undercloud virtual machine and become the non-root user (stack by default):

   ssh root@<undercloud-machine>
   
   su - stack
   

3. In order to use CLI commands easily you need to source needed environment variables:

   source stackrc
   

Get Images¶

ironic-python-agent.initramfs
ironic-python-agent.kernel
overcloud-full.initrd
overcloud-full.qcow2
overcloud-full.vmlinuz

Images must be built prior to doing a deployment. An IPA ramdisk and openstack-full image can all be built using tripleo-common.

It’s recommended to build images on the installed undercloud directly since all the dependencies are already present, but this is not a requirement.

The following steps can be used to build images. They should be run as the same non-root user that was used to install the undercloud. If the images are not created on the undercloud, one should use a non-root user.

1. Choose image operating system:

   CentOS

   The image build with no arguments will build CentOS 7. It will include the common YAML of /usr/share/openstack-tripleo-common/image-yaml/overcloud-images.yaml and the CentOS YAML at /usr/share/openstack-tripleo-common/image-yaml/overcloud-images-centos7.yaml.

   RHEL

   The common YAML is /usr/share/openstack-tripleo-common/image-yaml/overcloud-images.yaml. It must be specified along with the following.

   The default YAML for RHEL is /usr/share/openstack-tripleo-common/image-yaml/overcloud-images-rhel7.yaml

   export OS_YAML="/usr/share/openstack-tripleo-common/image-yaml/overcloud-images-rhel7.yaml"
   

2. Install the current-tripleo delorean repository and deps repository:

   Download and install the python2-tripleo-repos RPM from the current RDO repository. For example

   sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-<version>.el7.centos.noarch.rpm
   

   Note

   tripleo-repos removes any repositories that it manages before each run. This means all repositories must be specified in a single tripleo-repos call. As an example, the correct way to install the current and ceph repos is to run tripleo-repos current ceph, not two separate calls.

   Stable Branch

   Enable the appropriate repos for the desired release, as indicated below. Do not enable any other repos not explicitly marked for that release.

   Newton

   Enable the current Newton repositories

   sudo -E tripleo-repos -b newton current
   

   Ceph

   Include the Ceph repo in the tripleo-repos call

   sudo -E tripleo-repos -b newton current ceph
   

   Ocata

   Enable the current Ocata repositories

   sudo -E tripleo-repos -b ocata current
   

   Ceph

   Include the Ceph repo in the tripleo-repos call

   sudo -E tripleo-repos -b ocata current ceph
   

   Pike

   Enable the current Pike repositories

   sudo -E tripleo-repos -b pike current
   

   Ceph

   Include the Ceph repo in the tripleo-repos call

   sudo -E tripleo-repos -b pike current ceph
   

   Queens

   Enable the current Queens repositories

   sudo -E tripleo-repos -b queens current
   

   Ceph

   Include the Ceph repo in the tripleo-repos call

   sudo -E tripleo-repos -b queens current ceph
   

   Warning

   The remaining repositories configuration steps below should not be done for stable releases!

   Run tripleo-repos to install the appropriate repositories. The option below will enable the latest master TripleO packages and the latest promoted packages for all other OpenStack services and dependencies. There are other repository configurations available in tripleo-repos, see its --help output for details.

   sudo -E tripleo-repos current-tripleo-dev
   

   Ceph

   Include the Ceph repository in the tripleo-repos command

   sudo -E tripleo-repos current-tripleo-dev ceph
   

3. Export environment variables

   export DIB_YUM_REPO_CONF="/etc/yum.repos.d/delorean*"
   

   Ceph

   export DIB_YUM_REPO_CONF="$DIB_YUM_REPO_CONF /etc/yum.repos.d/tripleo-centos-ceph-jewel.repo"
   

   Stable Branch

   Newton

   export STABLE_RELEASE="newton"
   

   Ceph

   export DIB_YUM_REPO_CONF="$DIB_YUM_REPO_CONF /etc/yum.repos.d/tripleo-centos-ceph-jewel.repo"
   

   Ocata

   export STABLE_RELEASE="ocata"
   

   Ceph

   export DIB_YUM_REPO_CONF="$DIB_YUM_REPO_CONF /etc/yum.repos.d/tripleo-centos-ceph-jewel.repo"
   

4. Build the required images:

   RHEL

   Download the RHEL 7.4 cloud image or copy it over from a different location, for example: https://access.redhat.com/downloads/content/69/ver=/rhel---7/7.4/x86_64/product-software, and define the needed environment variables for RHEL 7.4 prior to running tripleo-build-images:

   export DIB_LOCAL_IMAGE=rhel-server-7.4-x86_64-kvm.qcow2
   

   RHEL Portal Registration

   To register the image builds to the Red Hat Portal define the following variables:

   export REG_METHOD=portal
   export REG_USER="[your username]"
   export REG_PASSWORD="[your password]"
   # Find this with `sudo subscription-manager list --available`
   export REG_POOL_ID="[pool id]"
   export REG_REPOS="rhel-7-server-rpms rhel-7-server-extras-rpms rhel-ha-for-rhel-7-server-rpms \
       rhel-7-server-optional-rpms rhel-7-server-openstack-6.0-rpms"
   

   Ceph

   If using Ceph, additional channels need to be added to REG_REPOS. Enable the appropriate channels for the desired release, as indicated below. Do not enable any other channels not explicitly marked for that release.

   rhel-7-server-rhceph-2-mon-rpms
   rhel-7-server-rhceph-2-osd-rpms
   rhel-7-server-rhceph-2-tools-rpms
   

   RHEL Satellite Registration

   To register the image builds to a Satellite define the following variables. Only using an activation key is supported when registering to Satellite, username/password is not supported for security reasons. The activation key must enable the repos shown:

   export REG_METHOD=satellite
   # REG_SAT_URL should be in the format of:
   # http://<satellite-hostname>
   export REG_SAT_URL="[satellite url]"
   export REG_ORG="[satellite org]"
   # Activation key must enable these repos:
   # rhel-7-server-rpms
   # rhel-7-server-optional-rpms
   # rhel-7-server-extras-rpms
   # rhel-7-server-openstack-6.0-rpms
   # rhel-7-server-rhceph-{2,1.3}-mon-rpms
   # rhel-7-server-rhceph-{2,1.3}-osd-rpms
   # rhel-7-server-rhceph-{2,1.3}-tools-rpms
   export REG_ACTIVATION_KEY="[activation key]"
   

   openstack overcloud image build
   

   RHEL

   openstack overcloud image build --config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-images.yaml --config-file $OS_YAML
   

   See the help for openstack overcloud image build for further options.

   The YAML files are cumulative. Order on the command line is important. The packages, elements, and options sections will append. All others will overwrite previously read values.

   Note

   This command will build overcloud-full images (*.qcow2, *.initrd, *.vmlinuz) and ironic-python-agent images (*.initramfs, *.kernel)

   In order to build specific images, one can use the --image-name flag to openstack overcloud image build. It can be specified multiple times.

Upload Images¶

Load the images into the containerized undercloud Glance:

openstack overcloud image upload

To upload a single image, see Uploading a Single Image.

If working with multiple atchitectures and/or plaforms with an architecure these attributes can be specified at upload time as in:

openstack overcloud image upload
openstack overcloud image upload --arch x86_64 \
    --httpboot /var/lib/ironic/httpboot/x86_64
openstack overcloud image upload --arch x86_64 --platform SNB \
    --httpboot /var/lib/ironic/httpboot/x86_64-SNB

This will create 3 sets of images with in the undercloud image service for later use in deployment, see Baremetal Environment

Register Nodes¶

Register and configure nodes for your deployment with Ironic:

openstack overcloud node import instackenv.json

The file to be imported may be either JSON, YAML or CSV format, and the type is detected via the file extension (json, yaml, csv). The file format is documented in instackenv.json.

The nodes status will be set to manageable by default, so that introspection may later be run. To also run introspection and make the nodes available for deployment in one step, the following flags can be used:

openstack overcloud node import --introspect --provide instackenv.json

Starting with the Newton release you can take advantage of the enroll provisioning state - see Bare Metal Node States for details.

If your hardware has several hard drives, it’s highly recommended that you specify the exact device to be used during introspection and deployment as a root device. Please see Setting the Root Device for Deployment for details.

If there is information from previous deployments on the nodes’ disks, it is recommended to at least remove the partitions and partition table(s). See Node cleaning for information on how to do it.

Finally, if you want your nodes to boot in the UEFI mode, additional steps may have to be taken - see Booting in UEFI mode for details.

Another approach to enrolling node is Node Discovery.

Introspect Nodes¶

openstack workflow execution create tripleo.validations.v1.run_groups '{"group_names": ["pre-introspection"]}'

Nodes must be in the manageable provisioning state in order to run introspection. Introspect hardware attributes of nodes with:

openstack overcloud node introspect --all-manageable

Nodes can also be specified individually by UUID. The --provide flag can be used in order to move the nodes automatically to the available provisioning state once the introspection is finished, making the nodes available for deployment.

openstack overcloud node introspect --all-manageable --provide

Provide Nodes¶

Only nodes in the available provisioning state can be deployed to (see Bare Metal Node States for details). To move nodes from manageable to available the following command can be used:

openstack overcloud node provide --all-manageable

Flavor Details¶

The undercloud will have a number of default flavors created at install time. In most cases these flavors do not need to be modified, but they can be if desired. By default, all overcloud instances will be booted with the baremetal flavor, so all baremetal nodes must have at least as much memory, disk, and cpu as that flavor.

In addition, there are profile-specific flavors created which can be used with the profile-matching feature. For more details on deploying with profiles, see Advanced Profile Matching.

Configure a nameserver for the Overcloud¶

Overcloud nodes can have a nameserver configured in order to resolve hostnames via DNS. The nameserver is defined in the undercloud’s neutron subnet. If needed, define the nameserver to be used for the environment:

# List the available subnets
openstack subnet list
openstack subnet set <subnet-uuid> --dns-nameserver <nameserver-ip>

neutron subnet-list
neutron subnet-update <subnet-uuid> --dns-nameserver <nameserver-ip>

Deploy the Overcloud¶

openstack workflow execution create tripleo.validations.v1.run_groups '{"group_names": ["pre-deployment"]}'

By default 1 compute and 1 control node will be deployed, with networking configured for the virtual environment. To customize this, see the output of:

openstack help overcloud deploy

-e /usr/share/openstack-tripleo-heat-templates/environments/enable-swap-partition.yaml
-e /usr/share/openstack-tripleo-heat-templates/environments/enable-swap.yaml

--ceph-storage-scale <number of nodes> -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml

-e /usr/share/openstack-tripleo-heat-templates/environments/hyperconverged-ceph.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml

--rhel-reg --reg-method satellite --reg-org <ORG ID#> --reg-sat-url <satellite URL> --reg-activation-key <KEY>

Run the deploy command, including any additional parameters as necessary:

openstack overcloud deploy --templates [additional parameters]

openstack overcloud deploy --templates -r my_roles_data.yaml
heat stack-delete overcloud

openstack overcloud deploy --templates

openstack overcloud deploy --templates -r my_roles_data.yaml
openstack overcloud delete <stack name>

openstack overcloud deploy --templates

To deploy an overcloud with multiple controllers and achieve HA, follow Configuring High Availability.

Post-Deployment¶

openstack workflow execution create tripleo.validations.v1.run_groups '{"group_names": ["post-deployment"]}'

source ~/overcloudrc

source ~/stackrc

openstack stack output show overcloud HostsEntry -f value -c output_value

openstack network create public --external --provider-network-type flat \
--provider-physical-network datacentre
openstack subnet create --allocation-pool start=172.16.23.140,end=172.16.23.240 \
--network public --gateway 172.16.23.251 --no-dhcp --subnet-range \
172.16.23.128/25 public

openstack network list

+--------------------------------------+----------+--------------------------------------+
| ID                                   | Name     | Subnets                              |
+--------------------------------------+----------+--------------------------------------+
| 4db8dd5d-fab5-4ea9-83e5-bdedbf3e9ee6 | public   | 7a315c5e-f8e2-495b-95e2-48af9442af01 |
+--------------------------------------+----------+--------------------------------------+

openstack network create public --external --provider-network-type vlan \
--provider-physical-network datacentre --provider-segment 195 \
openstack subnet create --allocation-pool start=172.16.23.140,end=172.16.23.240 \
--network public --no-dhcp --gateway 172.16.23.251 \
--subnet-range 172.16.23.128/25 public