Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 4. Installing director on the undercloud
To configure and install director, set the appropriate parameters in the undercloud.conf file and run the undercloud installation command. After you have installed director, import the overcloud images that director will use to write to bare metal nodes during node provisioning.
4.1. Configuring the undercloud Copier lienLien copié sur presse-papiers!
You must configure the undercloud before installing director. You configure the undercloud in the undercloud.conf file, which director reads from the home directory of the stack user.
Procedure
-
Log in to the undercloud as the
stackuser. Copy the sample
undercloud.conffile to the home directory of thestackuser:cp \ /usr/share/python-tripleoclient/undercloud.conf.sample \ ~/undercloud.conf
[stack@director ~]$ cp \ /usr/share/python-tripleoclient/undercloud.conf.sample \ ~/undercloud.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow Modify the values of the parameters in the
undercloud.conffile for your deployment. For information about the parameters you can use to configure the undercloud, see Undercloud configuration parameters.NoteIf you omit or comment out a parameter, director uses the default value.
-
Save your
undercloud.conffile.
4.2. Undercloud configuration parameters Copier lienLien copié sur presse-papiers!
The following list contains information about parameters for configuring the undercloud.conf file. Keep all parameters within their relevant sections to avoid errors.
At minimum, you must set the container_images_file parameter to the environment file that contains your container image configuration. Without this parameter properly set to the appropriate file, director cannot obtain your container image rule set from the ContainerImagePrepare parameter nor your container registry authentication details from the ContainerImageRegistryCredentials parameter.
Defaults
The following parameters are defined in the [DEFAULT] section of the undercloud.conf file:
- additional_architectures
-
A list of additional (kernel) architectures that an overcloud supports. Currently the overcloud supports only the
x86_64architecture. - certificate_generation_ca
-
The
certmongernickname of the CA that signs the requested certificate. Use this option only 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 the certificate to the trust chain. - clean_nodes
- Defines whether to wipe the hard drive between deployments and after introspection.
- cleanup
-
Delete temporary files. Set this to
Falseto retain the temporary files used during deployment. The temporary files can help you debug the deployment if errors occur. - container_cli
-
The CLI tool for container management. Leave this parameter set to
podman. Red Hat Enterprise Linux 9.2 only supportspodman. - container_healthcheck_disabled
-
Disables containerized service health checks. Red Hat recommends that you enable health checks and leave this option set to
false. - container_images_file
Heat environment file with container image information. This file can contain the following entries:
- Parameters for all required container images
-
The
ContainerImagePrepareparameter to drive the required image preparation. Usually the file that contains this parameter is namedcontainers-prepare-parameter.yaml.
- container_insecure_registries
-
A list of insecure registries for
podmanto use. Use this parameter if you want to pull images from another source, such as a private container registry. In most cases,podmanhas the certificates to pull container images from either the Red Hat Container Catalog or from your Satellite Server if the undercloud is registered to Satellite. - container_registry_mirror
-
An optional
registry-mirrorconfigured thatpodmanuses. - custom_env_files
- Additional environment files that you want to add to the undercloud installation.
- deployment_user
-
The user who installs the undercloud. Leave this parameter unset to use the current default user
stack. - discovery_default_driver
-
Sets the default driver for automatically enrolled nodes. Requires the
enable_node_discoveryparameter to be enabled and you must include the driver in theenabled_hardware_typeslist. - enable_ironic; enable_ironic_inspector; enable_tempest; enable_validations
-
Defines the core services that you want to enable for director. Leave these parameters set to
true. - enable_node_discovery
-
Automatically enroll any unknown node that PXE-boots the introspection ramdisk. New nodes use the
fakedriver as a default but you can setdiscovery_default_driverto override. You can also use introspection rules to specify driver information for newly enrolled nodes. - enable_routed_networks
- Defines whether to enable support for routed control plane networks.
- enabled_hardware_types
- A list of hardware types that you want to enable for the undercloud.
- 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. - heat_container_image
- URL for the heat container image to use. Leave unset.
- heat_native
-
Run host-based undercloud configuration using
heat-all. Leave astrue. - 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. For more information about using this feature, see Configuring hieradata on the undercloud. - inspection_extras
-
Defines whether to enable extra hardware collection during the inspection process. This parameter requires the
python-hardwareorpython-hardware-detectpackages on the introspection image. - inspection_interface
-
The bridge that director uses for node introspection. This is a custom bridge that the director configuration creates. The
LOCAL_INTERFACEattaches to this bridge. Leave this as the defaultbr-ctlplane. - inspection_runbench
-
Runs a set of benchmarks during node introspection. Set this parameter to
trueto enable the benchmarks. This option is necessary if you intend to perform benchmark analysis when inspecting the hardware of registered nodes. - ipv6_address_mode
IPv6 address configuration mode for the undercloud provisioning network. The following list contains the possible values for this parameter:
- dhcpv6-stateless - Address configuration using router advertisement (RA) and optional information using DHCPv6.
- dhcpv6-stateful - Address configuration and optional information using DHCPv6.
- ipxe_enabled
-
Defines whether to use iPXE or standard PXE. The default is
true, which enables iPXE. Set this parameter tofalseto use standard PXE. For PowerPC deployments, or for hybrid PowerPC and x86 deployments, set this value tofalse. - local_interface
The chosen interface for the director Provisioning NIC. This is also the device that director uses for 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
em0and the Provisioning NIC usesem1, which is currently not configured. In this case, set thelocal_interfacetoem1. The configuration script attaches this interface to a custom bridge defined with theinspection_interfaceparameter.- local_ip
The IP address defined for the director Provisioning NIC. This is also the IP address that director uses for DHCP and PXE boot services. Leave this value as the default
192.168.24.1/24unless you use a different subnet for the Provisioning network, for example, if this IP address conflicts with an existing IP address or subnet in your environment.For IPv6, the local IP address prefix length must be
/64to support both stateful and stateless connections.- local_mtu
-
The maximum transmission unit (MTU) that you want to use for the
local_interface. Do not exceed 1500 for the undercloud. - local_subnet
-
The local subnet that you want to use for PXE boot and DHCP interfaces. The
local_ipaddress should reside in this subnet. The default isctlplane-subnet. - net_config_override
-
Path to network configuration override template. If you set this parameter, the undercloud uses a JSON or YAML format template to configure the networking with
os-net-configand ignores the network parameters set inundercloud.conf. Use this parameter when you want to configure bonding or add an option to the interface. For more information about customizing undercloud network interfaces, see Configuring undercloud network interfaces. - networks_file
-
Networks file to override for
heat. - output_dir
- Directory to output state, processed heat templates, and Ansible deployment files.
- overcloud_domain_name
The DNS domain name that you want to use when you deploy the overcloud.
NoteWhen you configure the overcloud, you must set the
CloudDomainparameter to a matching value. Set this parameter in an environment file when you configure your overcloud.- roles_file
- The roles file that you want to use to override the default roles file for undercloud installation. It is highly recommended to leave this parameter unset so that the director installation uses the default roles file.
- scheduler_max_attempts
- The maximum number of times that the scheduler attempts to deploy an instance. This value must be greater or equal to the number of bare metal nodes that you expect to deploy at once to avoid potential race conditions when scheduling.
- service_principal
- The Kerberos principal for the service using the certificate. Use this parameter only if your CA requires a Kerberos principal, such as in FreeIPA.
- subnets
-
List of routed network subnets for provisioning and introspection. The default value includes only the
ctlplane-subnetsubnet. For more information, see Subnets. - templates
- Heat templates file to override.
- 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.If the
undercloud_admin_hostis not in the same IP network as thelocal_ip, you must configure the interface on which you want the admin APIs on the undercloud to listen. By default, the admin APIs listen on thebr-ctlplaneinterface. For information about how to configure undercloud network interfaces, see Configuring undercloud network interfaces.- undercloud_debug
-
Sets the log level of undercloud services to
DEBUG. Set this value totrueto enableDEBUGlog level. - undercloud_enable_selinux
-
Enable or disable SELinux during the deployment. It is highly recommended to leave this value set to
trueunless you are debugging an issue. - 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 you must configure all system host name settings appropriately.
- undercloud_log_file
-
The path to a log file to store the undercloud install and upgrade logs. By default, the log file is
install-undercloud.login the home directory. For example,/home/stack/install-undercloud.log. - 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 date and time.
- 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.If the
undercloud_public_hostis not in the same IP network as thelocal_ip, you must set thePublicVirtualInterfaceparameter to the public-facing interface on which you want the public APIs on the undercloud to listen. By default, the public APIs listen on thebr-ctlplaneinterface. Set thePublicVirtualInterfaceparameter in a custom environment file, and include the custom environment file in theundercloud.conffile by configuring thecustom_env_filesparameter.For information about customizing undercloud network interfaces, see Configuring undercloud network interfaces.
- 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.
- undercloud_timezone
- Host timezone for the undercloud. If you do not specify a timezone, director uses the existing timezone configuration.
- undercloud_update_packages
- Defines whether to update packages during the undercloud installation.
Subnets
Each provisioning subnet is a named section in the undercloud.conf file. For example, to create a subnet called ctlplane-subnet, use the following sample in your undercloud.conf file:
You can specify as many provisioning networks as necessary to suit your environment.
Director cannot change the IP addresses for a subnet after director creates the subnet.
- cidr
-
The network that director uses to manage overcloud instances. This is the Provisioning network, which the undercloud
neutronservice manages. Leave this as the default192.168.24.0/24unless you use 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 network address translation (NAT) so that the Provisioning network has external access through director.NoteThe director configuration also enables IP forwarding automatically using the relevant
sysctlkernel parameter.- dhcp_start; dhcp_end
The start and end of the DHCP allocation range for overcloud nodes. Ensure that this range contains enough IP addresses to allocate to your nodes. If not specified for the subnet, director determines the allocation pools by removing the values set for the
local_ip,gateway,undercloud_admin_host,undercloud_public_host, andinspection_iprangeparameters from the subnets full IP range.You can configure non-contiguous allocation pools for undercloud control plane subnets by specifying a list of start and end address pairs. Alternatively, you can use the
dhcp_excludeoption to exclude IP addresses within an IP address range. For example, the following configurations both create allocation pools172.20.0.100-172.20.0.150and172.20.0.200-172.20.0.250:Option 1
dhcp_start = 172.20.0.100,172.20.0.200 dhcp_end = 172.20.0.150,172.20.0.250
dhcp_start = 172.20.0.100,172.20.0.200 dhcp_end = 172.20.0.150,172.20.0.250Copy to Clipboard Copied! Toggle word wrap Toggle overflow Option 2
dhcp_start = 172.20.0.100 dhcp_end = 172.20.0.250 dhcp_exclude = 172.20.0.151-172.20.0.199
dhcp_start = 172.20.0.100 dhcp_end = 172.20.0.250 dhcp_exclude = 172.20.0.151-172.20.0.199Copy to Clipboard Copied! Toggle word wrap Toggle overflow - dhcp_exclude
IP addresses to exclude in the DHCP allocation range. For example, the following configuration excludes the IP address
172.20.0.105and the IP address range172.20.0.210-172.20.0.219:dhcp_exclude = 172.20.0.105,172.20.0.210-172.20.0.219
dhcp_exclude = 172.20.0.105,172.20.0.210-172.20.0.219Copy to Clipboard Copied! Toggle word wrap Toggle overflow - dns_nameservers
-
DNS nameservers specific to the subnet. If no nameservers are defined for the subnet, the subnet uses nameservers defined in the
undercloud_nameserversparameter. - 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 use a different IP address for director or want to use an external gateway directly. - host_routes
-
Host routes for the Neutron-managed subnet for the overcloud instances on this network. This also configures the host routes for the
local_subneton the undercloud. - inspection_iprange
-
Temporary IP range for nodes on this network to use during the inspection process. This range must not overlap with the range defined by
dhcp_startanddhcp_endbut must be in the same IP subnet.
4.3. Configuring the undercloud with environment files Copier lienLien copié sur presse-papiers!
You configure the main parameters for the undercloud through the undercloud.conf file. You can also perform additional undercloud configuration with an environment file that contains heat parameters.
Procedure
-
Create an environment file named
/home/stack/templates/custom-undercloud-params.yaml. Edit this file and include your heat parameters. For example, to enable debugging for certain OpenStack Platform services include the following snippet in the
custom-undercloud-params.yamlfile:parameter_defaults: Debug: True
parameter_defaults: Debug: TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow For information on the heat parameters you can configure for the undercloud, see Common heat parameters for undercloud configuration.
- Save the environment file.
Edit your
undercloud.conffile and scroll to thecustom_env_filesparameter. Edit the parameter to point to yourcustom-undercloud-params.yamlenvironment file:custom_env_files = /home/stack/templates/custom-undercloud-params.yaml
custom_env_files = /home/stack/templates/custom-undercloud-params.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteYou can specify multiple environment files using a comma-separated list.
The director installation includes this environment file during the next undercloud installation or upgrade operation.
4.4. Common heat parameters for undercloud configuration Copier lienLien copié sur presse-papiers!
The following table contains some common heat parameters that you might set in a custom environment file for your undercloud.
| Parameter | Description |
|---|---|
|
|
Sets the undercloud |
|
|
Sets the undercloud |
|
| Enables debug mode. |
Set these parameters in your custom environment file under the parameter_defaults section:
parameter_defaults: Debug: True AdminPassword: "myp@ssw0rd!" AdminEmail: "admin@example.com"
parameter_defaults:
Debug: True
AdminPassword: "myp@ssw0rd!"
AdminEmail: "admin@example.com"
4.5. Configuring hieradata on the undercloud Copier lienLien copié sur presse-papiers!
You can provide custom configuration for services beyond the available undercloud.conf parameters by configuring Puppet hieradata on the director.
Procedure
-
Create a hieradata override file, for example,
/home/stack/hieradata.yaml. Add the customized hieradata to the file. For example, add the following snippet to modify the Compute (nova) service parameter
force_raw_imagesfrom the default value ofTruetoFalse: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 in theundercloud.conffile to the path of the new/home/stack/hieradata.yamlfile:hieradata_override = /home/stack/hieradata.yaml
hieradata_override = /home/stack/hieradata.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6. Installing director Copier lienLien copié sur presse-papiers!
Complete the following steps to install director and perform some basic post-installation tasks.
Procedure
Run the following command to install director on the undercloud:
openstack undercloud install
[stack@director ~]$ openstack undercloud installCopy to Clipboard Copied! Toggle word wrap Toggle overflow This command launches the director configuration script. Director installs additional packages, configures its services according to the configuration in the
undercloud.conf, and starts all the RHOSP service containers. This script takes several minutes to complete.The script generates two files:
-
/home/stack/tripleo-deploy/undercloud/tripleo-undercloud-passwords.yaml- A list of all passwords for the director services. -
/home/stack/stackrc- A set of initialization variables to help you access the director command line tools.
-
Confirm that the RHOSP service containers are running:
sudo podman ps -a --format "{{.Names}} {{.Status}}"[stack@director ~]$ sudo podman ps -a --format "{{.Names}} {{.Status}}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow The following command output indicates that the RHOSP service containers are running (
Up):Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 that 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 command line tools.
4.7. Obtaining images for overcloud nodes Copier lienLien copié sur presse-papiers!
Director requires several disk images to provision overcloud nodes:
- An introspection kernel and ramdisk for bare metal system introspection over PXE boot.
- A deployment kernel and ramdisk for system provisioning and deployment.
- An overcloud kernel, ramdisk, and full image, which form a base overcloud system that director writes to the hard disk of the node.
You can obtain and install the images you need. You can also obtain and install a basic image to provision a bare OS when you do not want to run any other Red Hat OpenStack Platform (RHOSP) services or consume one of your subscription entitlements.
If your RHOSP deployment uses IPv6, you must modify the overcloud image to disable the cloud-init network configuration. For more information on modifying an image, see the Red Hat Knowledgebase solution Modifying the Red Hat Linux OpenStack Platform Overcloud Image with virt-customize.
Starting with RHOSP 17.1.4, all kernel console logging arguments are removed because console logging can cause unacceptable latency issues in Compute workloads.
If your RHOSP 17.1.3 or earlier deployment includes a filter rule in nftables or iptables with a LOG action, and the kernel command line (/proc/cmdline) has console=tty50, logging actions can cause substantial latency in packet transmission.
If your 17.1.3 or earlier deployment has this configuration and you observe excessive latency, apply the workaround described in Knowledgebase solution Sometimes receiving packet(e.g. ICMP echo) has latency, around 190 ms.
If you update to RHOSP 17.1.4, perform the steps in the Knowledgebase solution first.
4.7.1. Installing the overcloud images Copier lienLien copié sur presse-papiers!
Your Red Hat OpenStack Platform (RHOSP) installation includes packages that provide you with the overcloud-hardened-uefi-full.qcow2 overcloud image for director. This image is necessary for deployment of the overcloud with the default CPU architecture, x86-64. Importing this image into director also installs introspection images on the director PXE server.
Procedure
-
Log in to the undercloud as the
stackuser. Source the
stackrcfile:source ~/stackrc
[stack@director ~]$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Install the
rhosp-director-images-uefi-x86_64andrhosp-director-images-ipa-x86_64packages:sudo dnf install rhosp-director-images-uefi-x86_64 rhosp-director-images-ipa-x86_64
(undercloud) [stack@director ~]$ sudo dnf install rhosp-director-images-uefi-x86_64 rhosp-director-images-ipa-x86_64Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the
imagesdirectory in the home directory of thestackuser,/home/stack/images:mkdir /home/stack/images
(undercloud) [stack@director ~]$ mkdir /home/stack/imagesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Skip this step if the directory already exists.
Extract the images archives to the
imagesdirectory:cd ~/images for i in /usr/share/rhosp-director-images/ironic-python-agent-latest.tar /usr/share/rhosp-director-images/overcloud-hardened-uefi-full-latest.tar; do tar -xvf $i; done
(undercloud) [stack@director ~]$ cd ~/images (undercloud) [stack@director images]$ for i in /usr/share/rhosp-director-images/ironic-python-agent-latest.tar /usr/share/rhosp-director-images/overcloud-hardened-uefi-full-latest.tar; do tar -xvf $i; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow Import the images into 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 command converts the image format from QCOW to RAW, and provides verbose updates on the status of the image upload progress.
Verify that the overcloud images are copied to
/var/lib/ironic/images/:ls -l /var/lib/ironic/images/
(undercloud) [stack@director images]$ ls -l /var/lib/ironic/images/ total 1955660 -rw-r--r--. 1 root 42422 40442450944 Jan 29 11:59 overcloud-hardened-uefi-full.rawCopy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that director has copied the introspection PXE images to
/var/lib/ironic/httpboot:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7.2. Minimal overcloud image Copier lienLien copié sur presse-papiers!
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 (RHOSP) services or consume one of your subscription entitlements.
Your RHOSP installation includes the overcloud-minimal package that provides you with the following overcloud images for director:
-
overcloud-minimal -
overcloud-minimal-initrd -
overcloud-minimal-vmlinuz
Procedure
-
Log in to the undercloud as the
stackuser. Source the
stackrcfile:source ~/stackrc
[stack@director ~]$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Install the
overcloud-minimalpackage:sudo dnf install rhosp-director-images-minimal
(undercloud) [stack@director ~]$ sudo dnf 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-17.1.tar
(undercloud) [stack@director ~]$ cd ~/images (undercloud) [stack@director images]$ tar xf /usr/share/rhosp-director-images/overcloud-minimal-latest-17.1.tarCopy to Clipboard Copied! Toggle word wrap Toggle overflow Import the images into director:
openstack overcloud image upload --image-path /home/stack/images/ --image-type os --os-image-name overcloud-minimal.qcow2
(undercloud) [stack@director images]$ openstack overcloud image upload --image-path /home/stack/images/ --image-type os --os-image-name overcloud-minimal.qcow2Copy to Clipboard Copied! Toggle word wrap Toggle overflow The command provides updates on the status of the image upload progress:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.8. Updating the undercloud configuration Copier lienLien copié sur presse-papiers!
If you need to change the undercloud configuration to suit new requirements, you can make changes to your undercloud configuration after installation, edit the relevant configuration files and re-run the openstack undercloud install command.
Procedure
Modify the undercloud configuration files. For example, edit the
undercloud.conffile and add theidrachardware type to the list of enabled hardware types:enabled_hardware_types = ipmi,redfish,idrac
enabled_hardware_types = ipmi,redfish,idracCopy to Clipboard Copied! Toggle word wrap Toggle overflow Run the
openstack undercloud installcommand to refresh your undercloud with the new changes:openstack undercloud install
[stack@director ~]$ openstack undercloud installCopy to Clipboard Copied! Toggle word wrap Toggle overflow Wait until the command runs to completion.
Initialize the
stackuser to use the command line tools,:source ~/stackrc
[stack@director ~]$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow The prompt now indicates that OpenStack commands authenticate and execute against the undercloud:
(undercloud) [stack@director ~]$Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that director has applied the new configuration. For this example, check the list of enabled hardware types:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
The undercloud re-configuration is complete.
4.9. Undercloud container registry Copier lienLien copié sur presse-papiers!
Red Hat Enterprise Linux 9.2 no longer includes the docker-distribution package, which installed a Docker Registry v2. To maintain the compatibility and the same level of feature, the director installation creates an Apache web server with a vhost called image-serve to provide a registry. This registry also uses port 8787/TCP with SSL disabled. The Apache-based registry is not containerized, which means that you must run the following command to restart the registry:
sudo systemctl restart httpd
$ sudo systemctl restart httpd
You can find the container registry logs in the following locations:
- /var/log/httpd/image_serve_access.log
- /var/log/httpd/image_serve_error.log.
The image content is served from /var/lib/image-serve. This location uses a specific directory layout and apache configuration to implement the pull function of the registry REST API.
The Apache-based registry does not support podman push nor buildah push commands, which means that you cannot push container images using traditional methods. To modify images during deployment, use the container preparation workflow, such as the ContainerImagePrepare parameter. To manage container images, use the container management commands:
- openstack tripleo container image list
- Lists all images stored on the registry.
- openstack tripleo container image show
- Show metadata for a specific image on the registry.
- openstack tripleo container image push
- Push an image from a remote registry to the undercloud registry.
- openstack tripleo container image delete
- Delete an image from the registry.
4.10. Contents of the default undercloud directory Copier lienLien copié sur presse-papiers!
In RHOSP 17, you can find all the configuration files in a single directory. The name of the directory is a combination of the openstack command used and the name of the stack. The directories have default locations but you can change the default locations by using the --working-dir option. You can use this option with any tripleoclient command that reads or creates files used with the deployment.
| Default location | Command |
|---|---|
| $HOME/tripleo-deploy/undercloud |
|
| $HOME/tripleo-deploy/<stack> |
|
| $HOME/overcloud-deploy/<stack> |
|
The following table details the files and directories contained in the ~/tripleo-deploy/undercloud directory.
| Directory | Description |
|---|---|
|
| The ephemeral Heat working directory containing the ephemeral Heat configuration and database backups. |
|
| The undercloud install and upgrade logs. |
|
| Ansible inventory for the overcloud. |
|
| Contains the generated environment files. |
|
| Contains saved undercloud outputs. |
|
| Contains the undercloud passwords. |
|
|
A tarball of the working directory, for example, |