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.
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