Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 4. Installing the undercloud
The first step to creating your Red Hat OpenStack Platform environment is to install the director on the undercloud system. This involves a few prerequisite steps to enable the necessary subscriptions and repositories.
4.1. Considerations when running the undercloud with a proxy Link kopierenLink in die Zwischenablage kopiert!
If your environment uses a proxy, review these considerations to best understand the different configuration methods of integrating parts of Red Hat OpenStack Platform with a proxy and the limitations of each method.
System-wide proxy configuration
					Use this method to configure proxy communication for all network traffic on the undercloud. To configure the proxy settings, edit the /etc/environment file and set the following environment variables:
				
- http_proxy
 - The proxy that you want to use for standard HTTP requests.
 - https_proxy
 - The proxy that you want to use for HTTPs requests.
 - no_proxy
 - A comma-separated list of domains that you want to exclude from proxy communications.
 
The system-wide proxy method has the following limitations:
- 
						The 
no_proxyvariable primarily uses domain names (www.example.com), domain suffixes (example.com), and domains with a wildcard (*.example.com). Most Red Hat OpenStack Platform services interpret IP addresses inno_proxybut certain services, such as container health checks, do not interpret IP addresses in theno_proxyenvironment variable due to limitations with cURL andwget. To use a system-wide proxy with the undercloud, disable container health checks with thecontainer_healthcheck_disabledparameter in theundercloud.conffile during installation. For more information, see BZ#1837458 - Container health checks fail to honor no_proxy CIDR notation. - 
						Some containers bind and parse the environment variables in 
/etc/environmentsincorrectly, which causes problems when running these services. For more information, see BZ#1916070 - proxy configuration updates in /etc/environment files are not being picked up in containers correctly and BZ#1918408 - mistral_executor container fails to properly set no_proxy environment parameter. 
dnf proxy configuration
					Use this method to configure dnf to run all traffic through a proxy. To configure the proxy settings, edit the /etc/dnf/dnf.conf file and set the following parameters:
				
- proxy
 - The URL of the proxy server.
 - proxy_username
 - The username that you want to use to connect to the proxy server.
 - proxy_password
 - The password that you want to use to connect to the proxy server.
 - proxy_auth_method
 - The authentication method used by the proxy server.
 
				For more information about these options, run man dnf.conf.
			
				The dnf proxy method has the following limitations:
			
- 
						This method provides proxy support only for 
dnf. - 
						The 
dnfproxy method does not include an option to exclude certain hosts from proxy communication. 
Red Hat Subscription Manager proxy
					Use this method to configure Red Hat Subscription Manager to run all traffic through a proxy. To configure the proxy settings, edit the /etc/rhsm/rhsm.conf file and set the following parameters:
				
- proxy_hostname
 - Host for the proxy.
 - proxy_scheme
 - The scheme for the proxy when writing out the proxy to repo definitions.
 - proxy_port
 - The port for the proxy.
 - proxy_username
 - The username that you want to use to connect to the proxy server.
 - proxy_password
 - The password to use for connecting to the proxy server.
 - no_proxy
 - A comma-separated list of hostname suffixes for specific hosts that you want to exclude from proxy communication.
 
				For more information about these options, run man rhsm.conf.
			
The Red Hat Subscription Manager proxy method has the following limitations:
- This method provides proxy support only for Red Hat Subscription Manager.
 - The values for the Red Hat Subscription Manager proxy configuration override any values set for the system-wide environment variables.
 
Transparent proxy
If your network uses a transparent proxy to manage application layer traffic, you do not need to configure the undercloud itself to interact with the proxy because proxy management occurs automatically. A transparent proxy can help overcome limitations associated with client-based proxy configuration in Red Hat OpenStack Platform.
4.2. Creating the stack user Link kopierenLink in die Zwischenablage kopiert!
				The director installation process requires a non-root user to execute commands. Use the following procedure to create the user named stack and set a password.
			
Procedure
- 
						Log into your undercloud as the 
rootuser. Create the
stackuser:useradd stack
[root@director ~]# useradd stackCopy to Clipboard Copied! Toggle word wrap Toggle overflow Set a password for the user:
passwd stack
[root@director ~]# passwd stackCopy to Clipboard Copied! Toggle word wrap Toggle overflow Disable password requirements when using
sudo:echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack chmod 0440 /etc/sudoers.d/stack
[root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack [root@director ~]# chmod 0440 /etc/sudoers.d/stackCopy to Clipboard Copied! Toggle word wrap Toggle overflow Switch to the new
stackuser:su - stack
[root@director ~]# su - stack [stack@director ~]$Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
				Continue the director installation as the stack user.
			
4.3. Creating directories for templates and images Link kopierenLink in die Zwischenablage kopiert!
The director uses system images and Heat templates to create the overcloud environment. To keep these files organized, we recommend creating directories for images and templates:
mkdir ~/images mkdir ~/templates
[stack@director ~]$ mkdir ~/images
[stack@director ~]$ mkdir ~/templates
4.4. Setting the undercloud hostname Link kopierenLink in die Zwischenablage kopiert!
The undercloud requires a fully qualified domain name for its installation and configuration process. The DNS server that you use must be able to resolve a fully qualified domain name. For example, you can use an internal or private DNS server. This means that you might need to set the hostname of your undercloud.
Procedure
Check the base and full hostname of the undercloud:
hostname hostname -f
[stack@director ~]$ hostname [stack@director ~]$ hostname -fCopy to Clipboard Copied! Toggle word wrap Toggle overflow If either of the previous commands do not report the correct fully-qualified hostname or report an error, use
hostnamectlto set a hostname:sudo hostnamectl set-hostname manager.example.com sudo hostnamectl set-hostname --transient manager.example.com
[stack@director ~]$ sudo hostnamectl set-hostname manager.example.com [stack@director ~]$ sudo hostnamectl set-hostname --transient manager.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow The director also requires an entry for the system’s hostname and base name in
/etc/hosts. The IP address in/etc/hostsmust match the address that you plan to use for your undercloud public API. For example, if the system is namedmanager.example.comand uses10.0.0.1for its IP address, then/etc/hostsrequires an entry like:10.0.0.1 manager.example.com manager
10.0.0.1 manager.example.com managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
4.5. Registering and updating your undercloud Link kopierenLink in die Zwischenablage kopiert!
Prerequisites
Before you install the director, complete the following tasks:
- Register the undercloud with Red Hat Subscription Manager
 - Subscribe to and enable the relevant repositories
 - Perform an update of your Red Hat Enterprise Linux packages
 
Procedure
Register your system with the Content Delivery Network. Enter your Customer Portal user name and password when prompted:
sudo subscription-manager register
[stack@director ~]$ sudo subscription-manager registerCopy to Clipboard Copied! Toggle word wrap Toggle overflow Find the entitlement pool ID for Red Hat OpenStack Platform director. For example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Locate the
Pool IDvalue and attach the Red Hat OpenStack Platform 13 entitlement:sudo subscription-manager attach --pool=Valid-Pool-Number-123456
[stack@director ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456Copy to Clipboard Copied! Toggle word wrap Toggle overflow Disable all default repositories, and then enable the required Red Hat Enterprise Linux repositories that contain packages that the director installation requires:
sudo subscription-manager repos --disable=* sudo subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-rh-common-rpms --enable=rhel-ha-for-rhel-7-server-rpms --enable=rhel-7-server-openstack-13-rpms --enable=rhel-7-server-rhceph-3-tools-rpms
[stack@director ~]$ sudo subscription-manager repos --disable=* [stack@director ~]$ sudo subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-rh-common-rpms --enable=rhel-ha-for-rhel-7-server-rpms --enable=rhel-7-server-openstack-13-rpms --enable=rhel-7-server-rhceph-3-tools-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantEnable only the repositories listed in Section 2.5, “Repository Requirements”. Do not enable any additional repositories because they can cause package and software conflicts.
Perform an update on your system to ensure that you have the latest base system packages:
sudo yum update -y
[stack@director ~]$ sudo yum update -yCopy to Clipboard Copied! Toggle word wrap Toggle overflow Reboot your system:
sudo reboot
[stack@director ~]$ sudo rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow The system is now ready for the director installation.
4.6. Installing the director packages Link kopierenLink in die Zwischenablage kopiert!
The following procedure installs packages relevant to the Red hat OpenStack Platform director.
Procedure
Install the command line tools for director installation and configuration:
sudo yum install -y python-tripleoclient
[stack@director ~]$ sudo yum install -y python-tripleoclientCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
4.7. Installing ceph-ansible Link kopierenLink in die Zwischenablage kopiert!
				The ceph-ansible package is required when you use Ceph Storage with Red Hat OpenStack Platform.
			
				If you use Red Hat Ceph Storage, or if your deployment uses an external Ceph Storage cluster, install the ceph-ansible package. For more information about integrating with an existing Ceph Storage cluster, see Integrating an Overcloud with an Existing Red Hat Ceph Cluster.
			
Procedure
Enable the Ceph Tools repository:
sudo subscription-manager repos --enable=rhel-7-server-rhceph-3-tools-rpms
[stack@director ~]$ sudo subscription-manager repos --enable=rhel-7-server-rhceph-3-tools-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Install the
ceph-ansiblepackage:sudo yum install -y ceph-ansible
[stack@director ~]$ sudo yum install -y ceph-ansibleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
4.8. Configuring the director Link kopierenLink in die Zwischenablage kopiert!
				The director installation process requires certain settings to determine your network configurations. The settings are stored in a template located in the stack user’s home directory as undercloud.conf. This procedure demonstrates how to use the default template as a foundation for your configuration.
			
Procedure
Red Hat provides a basic template to help determine the required settings for your installation. Copy this template to the
stackuser’s home directory:cp \ /usr/share/instack-undercloud/undercloud.conf.sample \ ~/undercloud.conf
[stack@director ~]$ cp \ /usr/share/instack-undercloud/undercloud.conf.sample \ ~/undercloud.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 
						Edit the 
undercloud.conffile. This file contains settings to configure your undercloud. If you omit or comment out a parameter, the undercloud installation uses the default value. 
4.9. Director configuration parameters Link kopierenLink in die Zwischenablage kopiert!
				The following is a list of parameters for configuring the undercloud.conf file. Keep all parameters within their relevant sections to avoid errors.
			
Defaults
					The following parameters are defined in the [DEFAULT] section of the undercloud.conf file:
				
- undercloud_hostname
 - Defines the fully qualified host name for the undercloud. If set, the undercloud installation configures all system host name settings. If left unset, the undercloud uses the current host name, but the user must configure all system host name settings appropriately.
 - local_ip
 - 
							The IP address defined for the director’s Provisioning NIC. This is also the IP address the director uses for its DHCP and PXE boot services. Leave this value as the default 
192.168.24.1/24unless you are using a different subnet for the Provisioning network, for example, if it conflicts with an existing IP address or subnet in your environment. - undercloud_public_host
 - 
							The IP address or hostname defined for director Public API endpoints over SSL/TLS. The director configuration attaches the IP address to the director software bridge as a routed IP address, which uses the 
/32netmask. - undercloud_admin_host
 - 
							The IP address or hostname defined for director Admin API endpoints over SSL/TLS. The director configuration attaches the IP address to the director software bridge as a routed IP address, which uses the 
/32netmask. - undercloud_nameservers
 - A list of DNS nameservers to use for the undercloud hostname resolution.
 - undercloud_ntp_servers
 - A list of network time protocol servers to help synchronize the undercloud’s date and time.
 - overcloud_domain_name
 The DNS domain name to use when deploying the overcloud.
NoteWhen configuring the overcloud, the
CloudDomainparameter must be set to a matching value. Set this parameter in an environment file when you configure your overcloud.- subnets
 - 
							List of routed network subnets for provisioning and introspection. See Subnets for more information. The default value only includes the 
ctlplane-subnetsubnet. - local_subnet
 - 
							The local subnet to use for PXE boot and DHCP interfaces. The 
local_ipaddress should reside in this subnet. The default isctlplane-subnet. - masquerade_network
 - 
							If you set 
masquerade: truein the[ctlplane-subnet]section of theundercloud.conffile, you must define an empty value in themasquerade_networkparameter. - undercloud_service_certificate
 - The location and filename of the certificate for OpenStack SSL/TLS communication. Ideally, you obtain this certificate from a trusted certificate authority. Otherwise generate your own self-signed certificate using the guidelines in Appendix A, SSL/TLS Certificate Configuration. These guidelines also contain instructions on setting the SELinux context for your certificate, whether self-signed or from an authority. This option has implications when deploying your overcloud. See Section 6.9, “Configure overcloud nodes to trust the undercloud CA” for more information.
 - generate_service_certificate
 - 
							Defines whether to generate an SSL/TLS certificate during the undercloud installation, which is used for the 
undercloud_service_certificateparameter. The undercloud installation saves the resulting certificate/etc/pki/tls/certs/undercloud-[undercloud_public_vip].pem. The CA defined in thecertificate_generation_caparameter signs this certificate. This option has implications when deploying your overcloud. See Section 6.9, “Configure overcloud nodes to trust the undercloud CA” for more information. - certificate_generation_ca
 - 
							The 
certmongernickname of the CA that signs the requested certificate. Only use this option if you have set thegenerate_service_certificateparameter. If you select thelocalCA, certmonger extracts the local CA certificate to/etc/pki/ca-trust/source/anchors/cm-local-ca.pemand adds it to the trust chain. - service_principal
 - The Kerberos principal for the service using the certificate. Only use this if your CA requires a Kerberos principal, such as in FreeIPA.
 - local_interface
 The chosen interface for the director’s Provisioning NIC. This is also the device the director uses for its DHCP and PXE boot services. Change this value to your chosen device. To see which device is connected, use the
ip addrcommand. For example, this is the result of anip addrcommand:Copy to Clipboard Copied! Toggle word wrap Toggle overflow In this example, the External NIC uses
eth0and the Provisioning NIC useseth1, which is currently not configured. In this case, set thelocal_interfacetoeth1. The configuration script attaches this interface to a custom bridge defined with theinspection_interfaceparameter.- local_mtu
 - 
							MTU to use for the 
local_interface. Do not exceed 1500 for the undercloud. - hieradata_override
 - 
							Path to 
hieradataoverride file that configures Puppet hieradata on the director, providing custom configuration to services beyond theundercloud.confparameters. If set, the undercloud installation copies this file to the/etc/puppet/hieradatadirectory and sets it as the first file in the hierarchy. See Section 4.10, “Configuring hieradata on the undercloud” for details on using this feature. - net_config_override
 - 
							Path to network configuration override template. If set, the undercloud uses a JSON format template to configure the networking with 
os-net-config. This ignores the network parameters set inundercloud.conf. Use this parameter when you want to configure bonding or add an option to the interface. See/usr/share/instack-undercloud/templates/net-config.json.templatefor an example. - inspection_interface
 - 
							The bridge the director uses for node introspection. This is custom bridge that the director configuration creates. The 
LOCAL_INTERFACEattaches to this bridge. Leave this as the defaultbr-ctlplane. - inspection_extras
 - 
							Defines whether to enable extra hardware collection during the inspection process. Requires 
python-hardwareorpython-hardware-detectpackage on the introspection image. - inspection_runbench
 - 
							Runs a set of benchmarks during node introspection. Set to 
trueto enable. This option is necessary if you intend to perform benchmark analysis when inspecting the hardware of registered nodes. See Section 6.2, “Inspecting the Hardware of Nodes” for more details. - inspection_enable_uefi
 - Defines whether to support introspection of nodes with UEFI-only firmware. For more information, see Appendix D, Alternative Boot Modes.
 - enable_node_discovery
 - 
							Automatically enroll any unknown node that PXE-boots the introspection ramdisk. New nodes use the 
fake_pxedriver as a default but you can setdiscovery_default_driverto override. You can also use introspection rules to specify driver information for newly enrolled nodes. - discovery_default_driver
 - 
							Sets the default driver for automatically enrolled nodes. Requires 
enable_node_discoveryenabled and you must include the driver in theenabled_driverslist. See Appendix B, Power Management Drivers for a list of supported drivers. - undercloud_debug
 - 
							Sets the log level of undercloud services to 
DEBUG. Set this value totrueto enable. - undercloud_update_packages
 - Defines whether to update packages during the undercloud installation.
 - enable_tempest
 - 
							Defines whether to install the validation tools. The default is set to 
false, but you can can enable usingtrue. - enable_telemetry
 - 
							Defines whether to install OpenStack Telemetry services (ceilometer, aodh, panko, gnocchi) in the undercloud. In Red Hat OpenStack Platform, the metrics backend for telemetry is provided by gnocchi. Setting 
enable_telemetryparameter totruewill install and set up telemetry services automatically. The default value isfalse, which disables telemetry on the undercloud. This parameter is required if using other products that consume metrics data, such as Red Hat CloudForms. - enable_ui
 - 
							Defines Whether to install the director’s web UI. This allows you to perform overcloud planning and deployments through a graphical web interface. For more information, see Chapter 7, Configuring a Basic Overcloud with the Web UI. Note that the UI is only available with SSL/TLS enabled using either the 
undercloud_service_certificateorgenerate_service_certificate. - enable_validations
 - Defines whether to install the requirements to run validations.
 - enable_novajoin
 - 
							Defines whether to install the 
novajoinmetadata service in the Undercloud. - ipa_otp
 - 
							Defines the one time password to register the Undercloud node to an IPA server. This is required when 
enable_novajoinis enabled. - ipxe_enabled
 - 
							Defines whether to use iPXE or standard PXE. The default is 
true, which enables iPXE. Set tofalseto set to standard PXE. For more information, see Appendix D, Alternative Boot Modes. - scheduler_max_attempts
 - Maximum number of times the scheduler attempts to deploy an instance. Keep this greater or equal to the number of bare metal nodes you expect to deploy at once to work around potential race condition when scheduling.
 - clean_nodes
 - Defines whether to wipe the hard drive between deployments and after introspection.
 - enabled_hardware_types
 - A list of hardware types to enable for the undercloud. See Appendix B, Power Management Drivers for a list of supported drivers.
 - additional_architectures
 - 
							A list of (kernel) architectures that an overcloud will support. Currently this is limited to 
ppc64le 
					When enabling support for ppc64le, you must also set ipxe_enabled to False
				
Passwords
					The following parameters are defined in the [auth] section of the undercloud.conf file:
				
- undercloud_db_password; undercloud_admin_token; undercloud_admin_password; undercloud_glance_password; etc
 The remaining parameters are the access details for all of the director’s services. No change is required for the values. The director’s configuration script automatically generates these values if blank in
undercloud.conf. You can retrieve all values after the configuration script completes. Only use alphanumeric values for these passwords as special characters can cause syntax errors.ImportantThe configuration file examples for these parameters use
<None>as a placeholder value. Setting these values to<None>leads to a deployment error.
Subnets
					Each provisioning subnet is a named section in the undercloud.conf file. For example, to create a subnet called ctlplane-subnet:
				
You can specify as many provisioning networks as necessary to suit your environment.
- gateway
 - 
							The gateway for the overcloud instances. This is the undercloud host, which forwards traffic to the External network. Leave this as the default 
192.168.24.1unless you are either using a different IP address for the director or want to directly use an external gateway. 
					The director’s configuration script also automatically enables IP forwarding using the relevant sysctl kernel parameter.
				
- cidr
 - 
							The network that the director uses to manage overcloud instances. This is the Provisioning network, which the undercloud’s 
neutronservice manages. Leave this as the default192.168.24.0/24unless you are using a different subnet for the Provisioning network. - masquerade
 - 
							Defines whether to masquerade the network defined in the 
cidrfor external access. This provides the Provisioning network with a degree of network address translation (NAT) so that it has external access through the director. If you set themasqueradeparameter totrue, you must define an empty masquerade network value in themasquerade_networkparameter in the[DEFAULT]section of theundercloud.conffile. - dhcp_start; dhcp_end
 - The start and end of the DHCP allocation range for overcloud nodes. Ensure this range contains enough IP addresses to allocate your nodes.
 - inspection_iprange
 - 
							A range of IP address that the director’s introspection service uses during the PXE boot and provisioning process. Use comma-separated values to define the start and end of this range. For example, 
192.168.24.100,192.168.24.120. Make sure this range contains enough IP addresses for your nodes and does not conflict with the range fordhcp_startanddhcp_end. 
Modify the values for these parameters to suit your configuration. When complete, save the file.
4.10. Configuring hieradata on the undercloud Link kopierenLink in die Zwischenablage kopiert!
				You can provide custom configuration for services beyond the available undercloud.conf parameters by configuring Puppet hieradata on the director. Perform the following procedure to use this feature.
			
Procedure
- 
						Create a hieradata override file, for example, 
/home/stack/hieradata.yaml. Add the customized hieradata to the file. For example, add the following to modify the Compute (nova) service parameter
force_raw_imagesfrom the default value of "True" to "False":nova::compute::force_raw_images: False
nova::compute::force_raw_images: FalseCopy to Clipboard Copied! Toggle word wrap Toggle overflow If there is no Puppet implementation for the parameter you want to set, then use the following method to configure the parameter:
nova::config::nova_config: DEFAULT/<parameter_name>: value: <parameter_value>nova::config::nova_config: DEFAULT/<parameter_name>: value: <parameter_value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow For example:
nova::config::nova_config: DEFAULT/network_allocate_retries: value: 20 ironic/serial_console_state_timeout: value: 15nova::config::nova_config: DEFAULT/network_allocate_retries: value: 20 ironic/serial_console_state_timeout: value: 15Copy to Clipboard Copied! Toggle word wrap Toggle overflow Set the
hieradata_overrideparameter to the path of the hieradata file in yourundercloud.conf:hieradata_override = /home/stack/hieradata.yaml
hieradata_override = /home/stack/hieradata.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
4.11. Installing the director Link kopierenLink in die Zwischenablage kopiert!
The following procedure installs the director and performs some basic post-installation tasks.
Procedure
Run the following command to install the director on the undercloud:
openstack undercloud install
[stack@director ~]$ openstack undercloud installCopy to Clipboard Copied! Toggle word wrap Toggle overflow This launches the director’s configuration script. The director installs additional packages and configures its services to suit the settings in the
undercloud.conf. This script takes several minutes to complete.The script generates two files when complete:
- 
								
undercloud-passwords.conf- A list of all passwords for the director’s services. - 
								
stackrc- A set of initialization variables to help you access the director’s command line tools. 
- 
								
 The script also starts all OpenStack Platform services automatically. Check the enabled services using the following command:
sudo systemctl list-units openstack-*
[stack@director ~]$ sudo systemctl list-units openstack-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow The script adds the
stackuser to thedockergroup to give thestackuser has access to container management commands. Refresh thestackuser’s permissions with the following command:exec su -l stack
[stack@director ~]$ exec su -l stackCopy to Clipboard Copied! Toggle word wrap Toggle overflow The command prompts you to log in again. Enter the stack user’s password.
To initialize the
stackuser to use the command line tools, run the following command:source ~/stackrc
[stack@director ~]$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow The prompt now indicates OpenStack commands authenticate and execute against the undercloud;
(undercloud) [stack@director ~]$Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
The director installation is complete. You can now use the director’s command line tools.
4.12. Obtaining images for overcloud nodes Link kopierenLink in die Zwischenablage kopiert!
The director requires several disk images for provisioning overcloud nodes. This includes:
- An introspection kernel and ramdisk - Used for bare metal system introspection over PXE boot.
 - A deployment kernel and ramdisk - Used for system provisioning and deployment.
 - An overcloud kernel, ramdisk, and full image - A base overcloud system that is written to the node’s hard disk.
 
The following procedure shows how to obtain and install these images.
4.12.1. Single CPU architecture overclouds Link kopierenLink in die Zwischenablage kopiert!
These images and procedures are necessary for deployment of the overcloud with the default CPU architecture, x86-64.
Procedure
Source the
stackrcfile to enable the director’s command line tools:source ~/stackrc
[stack@director ~]$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Install the
rhosp-director-imagesandrhosp-director-images-ipapackages:sudo yum install rhosp-director-images rhosp-director-images-ipa
(undercloud) [stack@director ~]$ sudo yum install rhosp-director-images rhosp-director-images-ipaCopy to Clipboard Copied! Toggle word wrap Toggle overflow Extract the images archives to the
imagesdirectory on thestackuser’s home (/home/stack/images):mkdir ~/images cd ~/images for i in /usr/share/rhosp-director-images/overcloud-full-latest-13.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-13.0.tar; do tar -xvf $i; done
(undercloud) [stack@director ~]$ mkdir ~/images (undercloud) [stack@director ~]$ cd ~/images (undercloud) [stack@director images]$ for i in /usr/share/rhosp-director-images/overcloud-full-latest-13.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-13.0.tar; do tar -xvf $i; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow Import these images into the director:
openstack overcloud image upload --image-path /home/stack/images/
(undercloud) [stack@director images]$ openstack overcloud image upload --image-path /home/stack/images/Copy to Clipboard Copied! Toggle word wrap Toggle overflow This will upload the following images into the director:
- 
									
bm-deploy-kernel - 
									
bm-deploy-ramdisk - 
									
overcloud-full - 
									
overcloud-full-initrd - 
									
overcloud-full-vmlinuz 
The script also installs the introspection images on the director’s PXE server.
- 
									
 Verify that the images uploaded successfully:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow This list will not show the introspection PXE images. The director copies these files to
/httpboot.ls -l /httpboot
(undercloud) [stack@director images]$ ls -l /httpboot total 341460 -rwxr-xr-x. 1 root root 5153184 Mar 31 06:58 agent.kernel -rw-r--r--. 1 root root 344491465 Mar 31 06:59 agent.ramdisk -rw-r--r--. 1 ironic-inspector ironic-inspector 337 Mar 31 06:23 inspector.ipxeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
4.12.2. Multiple CPU architecture overclouds Link kopierenLink in die Zwischenablage kopiert!
These are the images and procedures needed for deployment of the overcloud to enable support of additional CPU architectures. This is currently limited to ppc64le, Power Architecture.
Procedure
Source the
stackrcfile to enable the director’s command line tools:source ~/stackrc
[stack@director ~]$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Install the
rhosp-director-images-allpackage:sudo yum install rhosp-director-images-all
(undercloud) [stack@director ~]$ sudo yum install rhosp-director-images-allCopy to Clipboard Copied! Toggle word wrap Toggle overflow Extract the archives to an architecture specific directory under the
imagesdirectory on thestackuser’s home (/home/stack/images):cd ~/images for arch in x86_64 ppc64le ; do mkdir $arch ; done for arch in x86_64 ppc64le ; do for i in /usr/share/rhosp-director-images/overcloud-full-latest-13.0-${arch}.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-13.0-${arch}.tar ; do tar -C $arch -xf $i ; done ; done(undercloud) [stack@director ~]$ cd ~/images (undercloud) [stack@director images]$ for arch in x86_64 ppc64le ; do mkdir $arch ; done (undercloud) [stack@director images]$ for arch in x86_64 ppc64le ; do for i in /usr/share/rhosp-director-images/overcloud-full-latest-13.0-${arch}.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-13.0-${arch}.tar ; do tar -C $arch -xf $i ; done ; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow Import these images into the director:
cd ~/images openstack overcloud image upload --image-path ~/images/ppc64le --architecture ppc64le --whole-disk --http-boot /tftpboot/ppc64le openstack overcloud image upload --image-path ~/images/x86_64/ --http-boot /tftpboot
(undercloud) [stack@director ~]$ cd ~/images (undercloud) [stack@director images]$ openstack overcloud image upload --image-path ~/images/ppc64le --architecture ppc64le --whole-disk --http-boot /tftpboot/ppc64le (undercloud) [stack@director images]$ openstack overcloud image upload --image-path ~/images/x86_64/ --http-boot /tftpbootCopy to Clipboard Copied! Toggle word wrap Toggle overflow This uploads the following images into the director:
- 
									
bm-deploy-kernel - 
									
bm-deploy-ramdisk - 
									
overcloud-full - 
									
overcloud-full-initrd - 
									
overcloud-full-vmlinuz - 
									
ppc64le-bm-deploy-kernel - 
									
ppc64le-bm-deploy-ramdisk ppc64le-overcloud-fullThe script also installs the introspection images on the director PXE server.
- 
									
 Verify that the images uploaded successfully:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow This list will not show the introspection PXE images. The director copies these files to
/tftpboot.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
4.12.3. Minimal overcloud image Link kopierenLink in die Zwischenablage kopiert!
					You can use the overcloud-minimal image to provision a bare OS where you do not want to run any other Red Hat OpenStack Platform services or consume one of your subscription entitlements.
				
Procedure
Source the
stackrcfile to enable the director command line tools:source ~/stackrc
[stack@director ~]$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Install the
overcloud-minimalpackage:sudo yum install rhosp-director-images-minimal
(undercloud) [stack@director ~]$ sudo yum install rhosp-director-images-minimalCopy to Clipboard Copied! Toggle word wrap Toggle overflow Extract the images archives to the
imagesdirectory in the home directory of thestackuser (/home/stack/images):cd ~/images tar xf /usr/share/rhosp-director-images/overcloud-minimal-latest-13.0.tar
(undercloud) [stack@director ~]$ cd ~/images (undercloud) [stack@director images]$ tar xf /usr/share/rhosp-director-images/overcloud-minimal-latest-13.0.tarCopy to Clipboard Copied! Toggle word wrap Toggle overflow Import the images into director:
openstack overcloud image upload --image-path /home/stack/images/ --os-image-name overcloud-minimal.qcow2
(undercloud) [stack@director images]$ openstack overcloud image upload --image-path /home/stack/images/ --os-image-name overcloud-minimal.qcow2Copy to Clipboard Copied! Toggle word wrap Toggle overflow This script uploads the following images into director:
- 
									
overcloud-minimal - 
									
overcloud-minimal-initrd - 
									
overcloud-minimal-vmlinuz 
- 
									
 Verify that the images uploaded successfully:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
						The default overcloud-full.qcow2 image is a flat partition image. However, you can also import and use whole disk images. See Appendix C, Whole Disk Images for more information.
					
4.13. Setting a nameserver for the control plane Link kopierenLink in die Zwischenablage kopiert!
				If you intend for the overcloud to resolve external hostnames, such as cdn.redhat.com, it is recommended to set a nameserver on the overcloud nodes. For a standard overcloud without network isolation, the nameserver is defined using the undercloud’s control plane subnet. Use the following procedure to define nameservers for the environment.
			
Procedure
Source the
stackrcfile to enable the director’s command line tools:source ~/stackrc
[stack@director ~]$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Set the nameservers for the
ctlplane-subnetsubnet:openstack subnet set --dns-nameserver [nameserver1-ip] --dns-nameserver [nameserver2-ip] ctlplane-subnet
(undercloud) [stack@director images]$ openstack subnet set --dns-nameserver [nameserver1-ip] --dns-nameserver [nameserver2-ip] ctlplane-subnetCopy to Clipboard Copied! Toggle word wrap Toggle overflow Use the
--dns-nameserveroption for each nameserver.View the subnet to verify the nameserver:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
					If you aim to isolate service traffic onto separate networks, the overcloud nodes use the DnsServers parameter in your network environment files.
				
4.14. Next Steps Link kopierenLink in die Zwischenablage kopiert!
This completes the director configuration and installation. The next chapter explores basic overcloud configuration, including registering nodes, inspecting them, and then tagging them into various node roles.