Chapter 7. Creating the Overcloud

The final stage in creating your OpenStack environment is to run the openstack overcloud deploy command to create it. Before running this command, you should familiarize yourself with key options and how to include custom environment files. This chapter discusses the openstack overcloud deploy command and the options associated with it.

Warning

Do not run openstack overcloud deploy as a background process. The Overcloud creation might hang in mid-deployment if started as a background process.

7.1. Setting Overcloud Parameters

The following table lists the additional parameters when using the openstack overcloud deploy command.

Table 7.1. Deployment Parameters

Parameter
Description
Example
--templates [TEMPLATES]
The directory containing the Heat templates to deploy. If blank, the command uses the default template location at /usr/share/openstack-tripleo-heat-templates/
~/templates/my-overcloud
--stack STACK
The name of the stack to create or update
overcloud
-t [TIMEOUT], --timeout [TIMEOUT]
Deployment timeout in minutes
240
--control-scale [CONTROL_SCALE]
The number of Controller nodes to scale out
3
--compute-scale [COMPUTE_SCALE]
The number of Compute nodes to scale out
3
--ceph-storage-scale [CEPH_STORAGE_SCALE]
The number of Ceph Storage nodes to scale out
3
--block-storage-scale [BLOCK_STORAGE_SCALE]
The number of Cinder nodes to scale out
3
--swift-storage-scale [SWIFT_STORAGE_SCALE]
The number of Swift nodes to scale out
3
--control-flavor [CONTROL_FLAVOR]
The flavor to use for Controller nodes
control
--compute-flavor [COMPUTE_FLAVOR]
The flavor to use for Compute nodes
compute
--ceph-storage-flavor [CEPH_STORAGE_FLAVOR]
The flavor to use for Ceph Storage nodes
ceph-storage
--block-storage-flavor [BLOCK_STORAGE_FLAVOR]
The flavor to use for Cinder nodes
cinder-storage
--swift-storage-flavor [SWIFT_STORAGE_FLAVOR]
The flavor to use for Swift storage nodes
swift-storage
--neutron-flat-networks [NEUTRON_FLAT_NETWORKS]
(DEPRECATED) Defines the flat networks to configure in neutron plugins. Defaults to "datacentre" to permit external network creation
datacentre
--neutron-physical-bridge [NEUTRON_PHYSICAL_BRIDGE]
(DEPRECATED) An Open vSwitch bridge to create on each hypervisor. This defaults to "br-ex". Typically, this should not need to be changed
br-ex
--neutron-bridge-mappings [NEUTRON_BRIDGE_MAPPINGS]
(DEPRECATED) The logical to physical bridge mappings to use. Defaults to mapping the external bridge on hosts (br-ex) to a physical name (datacentre). You would use this for the default floating network
datacentre:br-ex
--neutron-public-interface [NEUTRON_PUBLIC_INTERFACE]
(DEPRECATED) Defines the interface to bridge onto br-ex for network nodes
nic1, eth0
--neutron-network-type [NEUTRON_NETWORK_TYPE]
(DEPRECATED) The tenant network type for Neutron
gre or vxlan
--neutron-tunnel-types [NEUTRON_TUNNEL_TYPES]
(DEPRECATED) The tunnel types for the Neutron tenant network. To specify multiple values, use a comma separated string
'vxlan' 'gre,vxlan'
--neutron-tunnel-id-ranges [NEUTRON_TUNNEL_ID_RANGES]
(DEPRECATED) Ranges of GRE tunnel IDs to make available for tenant network allocation
1:1000
--neutron-vni-ranges [NEUTRON_VNI_RANGES]
(DEPRECATED) Ranges of VXLAN VNI IDs to make available for tenant network allocation
1:1000
--neutron-disable-tunneling
(DEPRECATED) Disables tunneling in case you aim to use a VLAN segmented network or flat network with Neutron
--neutron-network-vlan-ranges [NEUTRON_NETWORK_VLAN_RANGES]
(DEPRECATED) The Neutron ML2 and Open vSwitch VLAN mapping range to support. Defaults to permitting any VLAN on the 'datacentre' physical network
datacentre:1:1000
--neutron-mechanism-drivers [NEUTRON_MECHANISM_DRIVERS]
(DEPRECATED) The mechanism drivers for the neutron tenant network. Defaults to "openvswitch". To specify multiple values, use a comma-separated string
'openvswitch,l2population'
--libvirt-type [LIBVIRT_TYPE]
Virtualization type to use for hypervisors
kvm,qemu
--ntp-server [NTP_SERVER]
Network Time Protocol (NTP) server to use to synchronize time. You can also specify multiple NTP servers in a comma-separated list, for example: --ntp-server 0.centos.pool.org,1.centos.pool.org. For a high availability cluster deployment, it is essential that your controllers are consistently referring to the same time source. Note that a typical environment might already have a designated NTP time source with established practices.
pool.ntp.org
--no-proxy [NO_PROXY]
Defines custom values for the environment variable no_proxy, which excludes certain domain extensions from proxy communication
--overcloud-ssh-user OVERCLOUD_SSH_USER
Defines the SSH user to access the Overcloud nodes. Normally SSH access occurs through the heat-admin user.
ocuser
-e [EXTRA HEAT TEMPLATE], --extra-template [EXTRA HEAT TEMPLATE]
Extra environment files to pass to the Overcloud deployment. Can be specified more than once. Note that the order of environment files passed to the openstack overcloud deploy command is important. For example, parameters from each sequential environment file override the same parameters from earlier environment files.
-e ~/templates/my-config.yaml
--validation-errors-fatal
The Overcloud creation process performs a set of pre-deployment checks. This option exits if any errors occur from the pre-deployment checks. It is advisable to use this option as any errors can cause your deployment to fail.
--validation-warnings-fatal
The Overcloud creation process performs a set of pre-deployment checks. This option exits if any non-critical warnings occur from the pre-deployment checks.
--dry-run
Performs validation check on the Overcloud but does not actually create the Overcloud.
--rhel-reg
Register Overcloud nodes to the Customer Portal or Satellite 6
--reg-method
Registration method to use for the overcloud nodes
satellite for Red Hat Satellite 6 or Red Hat Satellite 5, portal for Customer Portal
--reg-org [REG_ORG]
Organization to use for registration
--reg-force
Register the system even if it is already registered
--reg-sat-url [REG_SAT_URL]
The base URL of the Satellite server to register Overcloud nodes. Use the Satellite's HTTP URL and not the HTTPS URL for this parameter. For example, use http://satellite.example.com and not https://satellite.example.com. The Overcloud creation process uses this URL to determine whether the server is a Red Hat Satellite 5 or Red Hat Satellite 6 server. If a Red Hat Satellite 6 server, the Overcloud obtains the katello-ca-consumer-latest.noarch.rpm file, registers with subscription-manager, and installs katello-agent. If a Red Hat Satellite 5 server, the Overcloud obtains the RHN-ORG-TRUSTED-SSL-CERT file and registers with rhnreg_ks.
--reg-activation-key [REG_ACTIVATION_KEY]
Activation key to use for registration

Note

Run the following command for a full list of options:
$ openstack help overcloud deploy