Este conteúdo não está disponível no idioma selecionado.
Chapter 6. Configuring a basic overcloud with CLI tools
This chapter contains basic configuration procedures to deploy an OpenStack Platform environment using the CLI tools. An overcloud with a basic configuration contains no custom features. However, you can add advanced configuration options to this basic overcloud and customize it to your specifications using the instructions in the Advanced Overcloud Customization guide.
6.1. Registering Nodes for the Overcloud Copiar o linkLink copiado para a área de transferência!
The director requires a node definition template, which you create manually. This template uses a JSON or YAML format, and contains the hardware and power management details for your nodes.
Procedure
Create a template that lists your nodes. Use the following JSON and YAML template examples to understand how to structure your node definition template:
Example JSON template
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example YAML template
Copy to Clipboard Copied! Toggle word wrap Toggle overflow This template contains the following attributes:
- name
- The logical name for the node.
- pm_type
The power management driver to use. This example uses the IPMI driver (
ipmi).NoteIPMI is the preferred supported power management driver. For more supported power management types and their options, see Appendix A, Power Management Drivers. If these power management drivers do not work as expected, use IPMI for your power management.
- pm_user; pm_password
- The IPMI username and password.
- pm_addr
- The IP address of the IPMI device.
- pm_port (Optional)
- The port to access the specific IPMI device.
- mac
- (Optional) A list of MAC addresses for the network interfaces on the node. Use only the MAC address for the Provisioning NIC of each system.
- cpu
- (Optional) The number of CPUs on the node.
- memory
- (Optional) The amount of memory in MB.
- disk
- (Optional) The size of the hard disk in GB.
- arch
(Optional) The system architecture.
ImportantWhen building a multi-architecture cloud, the
archkey is mandatory to distinguish nodes usingx86_64andppc64learchitectures.
After creating the template, run the following commands to verify the formatting and syntax:
source ~/stackrc
$ source ~/stackrc (undercloud) $ openstack overcloud node import --validate-only ~/nodes.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow Save the file to the
stackuser’s home directory (/home/stack/nodes.json), then run the following command to import the template to the director:(undercloud) $ openstack overcloud node import ~/nodes.json
(undercloud) $ openstack overcloud node import ~/nodes.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow This command registers each node from the template into the director.
Wait for the node registration and configuration to completes. Once complete, confirm the director has successfully registered the nodes:
(undercloud) $ openstack baremetal node list
(undercloud) $ openstack baremetal node listCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2. Inspecting the hardware of nodes Copiar o linkLink copiado para a área de transferência!
The director can run an introspection process on each node. This process boots an introspection agent over PXE on each node. The introspection agent collects hardware data from the node and sends it back to the director. The director then stores this introspection data in the OpenStack Object Storage (swift) service running on the director. The director uses hardware information for various purposes such as profile tagging, benchmarking, and manual root disk assignment.
Procedure
Run the following command to inspect the hardware attributes of each node:
(undercloud) $ openstack overcloud node introspect --all-manageable --provide
(undercloud) $ openstack overcloud node introspect --all-manageable --provideCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
The
--all-manageableoption introspects only nodes in a managed state. In this example, all nodes are in a managed state. -
The
--provideoption resets all nodes to anavailablestate after introspection.
-
The
Monitor the progress of the introspection using the following command in a separate terminal window:
(undercloud) $ sudo tail -f /var/log/containers/ironic-inspector/ironic-inspector.log
(undercloud) $ sudo tail -f /var/log/containers/ironic-inspector/ironic-inspector.logCopy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantEnsure this process runs to completion. This process usually takes 15 minutes for bare metal nodes.
-
After the introspection completes, all nodes change to an
availablestate.
6.3. Tagging nodes into profiles Copiar o linkLink copiado para a área de transferência!
After registering and inspecting the hardware of each node, tag the nodes into specific profiles. These profile tags match your nodes to flavors, which assigns the flavors to deployment roles. The following example shows the relationships across roles, flavors, profiles, and nodes for Controller nodes:
| Type | Description |
|---|---|
| Role |
The |
| Flavor |
The |
| Profile |
The |
| Node |
You also apply the |
Default profile flavors compute, control, swift-storage, ceph-storage, and block-storage are created during undercloud installation and are usable without modification in most environments.
Procedure
To tag a node into a specific profile, add a
profileoption to theproperties/capabilitiesparameter for each node. For example, to tag your nodes to use Controller and Compute profiles respectively, use the following commands:(undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 (undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
(undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 (undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0Copy to Clipboard Copied! Toggle word wrap Toggle overflow The addition of the
profile:computeandprofile:controloptions tag the two nodes into each respective profiles.These commands also set the
boot_option:localparameter, which defines how each node boots.After completing node tagging, check the assigned profiles or possible profiles:
(undercloud) $ openstack overcloud profiles list
(undercloud) $ openstack overcloud profiles listCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4. Setting UEFI boot mode Copiar o linkLink copiado para a área de transferência!
The default boot mode is the legacy BIOS mode. Newer systems might require UEFI boot mode instead of the legacy BIOS mode. Complete the following steps to change the boot mode to UEFI mode.
Procedure
Set the following parameters in your
undercloud.conffile:ipxe_enabled = True inspection_enable_uefi = True
ipxe_enabled = True inspection_enable_uefi = TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Save the
undercloud.conffile and run the undercloud installation:openstack undercloud install
$ openstack undercloud installCopy to Clipboard Copied! Toggle word wrap Toggle overflow Wait until the installation script completes.
Set the boot mode to
uefifor each registered node. For example, to add or replace the existingboot_modeparameters in thecapabilitiesproperty, run the following command:NODE=<NODE NAME OR ID> ; openstack baremetal node set --property capabilities="boot_mode:uefi,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE
$ NODE=<NODE NAME OR ID> ; openstack baremetal node set --property capabilities="boot_mode:uefi,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODECopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteCheck that you have retained the
profileandboot_optioncapabilities:openstack baremetal node show r530-12 -f json -c properties | jq -r .properties.capabilities
$ openstack baremetal node show r530-12 -f json -c properties | jq -r .properties.capabilitiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Set the boot mode to
uefifor each flavor:openstack flavor set --property capabilities:boot_mode='uefi' control
$ openstack flavor set --property capabilities:boot_mode='uefi' controlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5. Defining the root disk for multi-disk clusters Copiar o linkLink copiado para a área de transferência!
Director must identify the root disk during provisioning in the case of nodes with multiple disks. For example, most Ceph Storage nodes use multiple disks. By default, the director writes the overcloud image to the root disk during the provisioning process
There are several properties that you can define to help the director identify the root disk:
-
model(String): Device identifier. -
vendor(String): Device vendor. -
serial(String): Disk serial number. -
hctl(String): Host:Channel:Target:Lun for SCSI. -
size(Integer): Size of the device in GB. -
wwn(String): Unique storage identifier. -
wwn_with_extension(String): Unique storage identifier with the vendor extension appended. -
wwn_vendor_extension(String): Unique vendor storage identifier. -
rotational(Boolean): True for a rotational device (HDD), otherwise false (SSD). -
name(String): The name of the device, for example: /dev/sdb1.
Use the name property only for devices with persistent names. Do not use name to set the root disk for any other devices because this value can change when the node boots.
Complete the following steps to specify the root device using its serial number.
Procedure
Check the disk information from the hardware introspection of each node. Run the following command to display the disk information of a node:
(undercloud) $ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"
(undercloud) $ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"Copy to Clipboard Copied! Toggle word wrap Toggle overflow For example, the data for one node might show three disks:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Run the
openstack baremetal node set --property root_device=command to set the root disk for a node. Include the most appropriate hardware attribute value to define the root disk.(undercloud) $ openstack baremetal node set --property root_device=’{“serial”:”<serial_number>”} <node-uuid>(undercloud) $ openstack baremetal node set --property root_device=’{“serial”:”<serial_number>”} <node-uuid>Copy to Clipboard Copied! Toggle word wrap Toggle overflow For example, to set the root device to disk 2, which has the serial number
61866da04f380d001ea4e13c12e36ad6run the following command:(undercloud) $ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0(undercloud) $ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Ensure that you configure the BIOS of each node to include booting from the root disk that you choose. Configure the boot order to boot from the network first, then to boot from the root disk.
The director identifies the specific disk to use as the root disk. When you run the openstack overcloud deploy command, the director provisions and writes the overcloud image to the root disk.
6.6. Using the overcloud-minimal image to avoid using a Red Hat subscription entitlement Copiar o linkLink copiado para a área de transferência!
By default, director writes the QCOW2 overcloud-full image to the root disk during the provisioning process. The overcloud-full image uses a valid Red Hat subscription. However, you can also use the overcloud-minimal image, for example, to provision a bare OS where you do not want to run any other OpenStack services and consume your subscription entitlements.
A common use case for this occurs when you want to provision nodes with only Ceph daemons. For this and similar use cases, you can use the overcloud-minimal image option to avoid reaching the limit of your paid Red Hat subscriptions. For information about how to obtain the overcloud-minimal image, see Obtaining images for overcloud nodes.
Procedure
To configure director to use the
overcloud-minimalimage, create an environment file that contains the following image definition:parameter_defaults: <roleName>Image: overcloud-minimal
parameter_defaults: <roleName>Image: overcloud-minimalCopy to Clipboard Copied! Toggle word wrap Toggle overflow Replace
<roleName>with the name of the role and appendImageto the name of the role. The following example shows anovercloud-minimalimage for Ceph storage nodes:parameter_defaults: CephStorageImage: overcloud-minimal
parameter_defaults: CephStorageImage: overcloud-minimalCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Pass the environment file to the
openstack overcloud deploycommand.
The overcloud-minimal image supports only standard Linux bridges and not OVS because OVS is an OpenStack service that requires an OpenStack subscription entitlement.
6.7. Creating architecture specific roles Copiar o linkLink copiado para a área de transferência!
When building a multi-architecture cloud, you must add any architecture specific roles to the roles_data.yaml file. The following example includes the ComputePPC64LE role along with the default roles:
openstack overcloud roles generate \
--roles-path /usr/share/openstack-tripleo-heat-templates/roles -o ~/templates/roles_data.yaml \
Controller Compute ComputePPC64LE BlockStorage ObjectStorage CephStorage
openstack overcloud roles generate \
--roles-path /usr/share/openstack-tripleo-heat-templates/roles -o ~/templates/roles_data.yaml \
Controller Compute ComputePPC64LE BlockStorage ObjectStorage CephStorage
The Creating a Custom Role File section has information on roles.
6.8. Environment files Copiar o linkLink copiado para a área de transferência!
The undercloud includes a set of Heat templates that form the plan for your overcloud creation. You can customize aspects of the overcloud using environment files, which are YAML-formatted files that override parameters and resources in the core Heat template collection. You can include as many environment files as necessary. However, the order of the environment files is important as the parameters and resources defined in subsequent environment files take precedence. Use the following list as an example of the environment file order:
- The number of nodes and the flavors for each role. It is vital to include this information for overcloud creation.
- The location of the container images for containerized OpenStack services.
Any network isolation files, starting with the initialization file (
environments/network-isolation.yaml) from the heat template collection, then your custom NIC configuration file, and finally any additional network configurations. See the following chapters in the Advanced Overcloud Customization guide for more information:- Any external load balancing environment files if you are using an external load balancer. See External Load Balancing for the Overcloud for more information.
- Any storage environment files such as Ceph Storage, NFS, iSCSI, etc.
- Any environment files for Red Hat CDN or Satellite registration.
- Any other custom environment files.
It is recommended to keep your custom environment files organized in a separate directory, such as the templates directory.
You can customize advanced features for your overcloud using the Advanced Overcloud Customization guide.
A basic overcloud uses local LVM storage for block storage, which is not a supported configuration. It is recommended to use an external storage solution, such as Red Hat Ceph Storage, for block storage.
The environment file extension must be .yaml or .template, or it will not be treated as a custom template resource.
The next few sections contain information about creating some environment files necessary for your overcloud.
6.9. Creating an environment file that defines node counts and flavors Copiar o linkLink copiado para a área de transferência!
By default, the director deploys an overcloud with 1 Controller node and 1 Compute node using the baremetal flavor. However, this is only suitable for a proof-of-concept deployment. You can override the default configuration by specifying different node counts and flavors. For a small scale production environment, you might want to consider at least 3 Controller nodes and 3 Compute nodes, and assign specific flavors to ensure the nodes have the appropriate resource specifications. Complete the following steps to create an environment file named node-info.yaml that stores the node counts and flavor assignments.
Procedure
Create a
node-info.yamlfile in the/home/stack/templates/directory:(undercloud) $ touch /home/stack/templates/node-info.yaml
(undercloud) $ touch /home/stack/templates/node-info.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the file to include the node counts and flavors your need. This example contains 3 Controller nodes and 3 Compute nodes:
parameter_defaults: OvercloudControllerFlavor: control OvercloudComputeFlavor: compute ControllerCount: 3 ComputeCount: 3
parameter_defaults: OvercloudControllerFlavor: control OvercloudComputeFlavor: compute ControllerCount: 3 ComputeCount: 3Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.10. Creating an environment file for undercloud CA trust Copiar o linkLink copiado para a área de transferência!
If your undercloud uses TLS and the Certificate Authority (CA) is not publicly trusted, you can use the CA for SSL endpoint encryption that the undercloud operates. To ensure the undercloud endpoints accessible to the rest of your deployment, configure your overcloud nodes to trust the undercloud CA.
For this approach to work, your overcloud nodes must have a network route to the undercloud’s public endpoint. It is likely that deployments that rely on spine-leaf networking will need to apply this configuration.
There are two types of custom certificates you can use in the undercloud:
-
User-provided certificates - This definition applies when you have provided your own certificate. This could be from your own CA, or it might be self-signed. This is passed using the
undercloud_service_certificateoption. In this case, you must either trust the self-signed certificate, or the CA (depending on your deployment). -
Auto-generated certificates - This definition applies when you use
certmongerto generate the certificate using its own local CA. This is enabled using thegenerate_service_certificateoption in theundercloud.conffile. In this case, the director generates a CA certificate at/etc/pki/ca-trust/source/anchors/cm-local-ca.pemand the director configures the undercloud’s HAProxy instance to use a server certificate. Add the CA certificate to theinject-trust-anchor-hiera.yamlfile to present the certificate to OpenStack Platform.
This example uses a self-signed certificate located in /home/stack/ca.crt.pem. If you use auto-generated certificates, use /etc/pki/ca-trust/source/anchors/cm-local-ca.pem instead.
Procedure
Open the certificate file and copy only the certificate portion. Do not include the key:
vi /home/stack/ca.crt.pem
$ vi /home/stack/ca.crt.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow The certificate portion you need will look similar to this shortened example:
-----BEGIN CERTIFICATE----- MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3 -----END CERTIFICATE-----
-----BEGIN CERTIFICATE----- MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3 -----END CERTIFICATE-----Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a new YAML file called
/home/stack/inject-trust-anchor-hiera.yamlwith the following contents, and include the certificate you copied from the PEM file:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
The certificate string must follow the PEM format.
The CAMap parameter might contain other certificates relevant to SSL/TLS configuration.
The CA certificate is copied to each overcloud node during the overcloud deployment. As a result, each node trusts the encryption presented by the undercloud’s SSL endpoints. For more information about environment files, see Section 6.13, “Including environment files in an overcloud deployment”.
6.11. Deployment command Copiar o linkLink copiado para a área de transferência!
The final stage in creating your OpenStack environment is to run the openstack overcloud deploy command to create the overcloud. Before running this command, you should familiarize yourself with key options and how to include custom environment files.
Do not run openstack overcloud deploy as a background process. The overcloud creation might hang mid-deployment if run as a background process.
6.12. Deployment command options Copiar o linkLink copiado para a área de transferência!
The following table lists the additional parameters for the openstack overcloud deploy command.
| Parameter | Description |
|---|---|
|
|
The directory containing the Heat templates to deploy. If blank, the command uses the default template location at |
|
| The name of the stack to create or update |
|
| Deployment timeout in minutes |
|
| Virtualization type to use for hypervisors |
|
|
Network Time Protocol (NTP) server to use to synchronize time. You can also specify multiple NTP servers in a comma-separated list, for example: |
|
| Defines custom values for the environment variable no_proxy, which excludes certain hostnames from proxy communication. |
|
|
Defines the SSH user to access the overcloud nodes. Normally SSH access occurs through the |
|
| Defines the key path for SSH access to overcloud nodes. |
|
| Defines the network name to use for SSH access to overcloud nodes. |
|
|
Extra environment files to pass to the overcloud deployment. You can specify this option more than once. Note that the order of environment files passed to the |
|
| The directory containing environment files to include in deployment. The deploy command processes these environment files in numerical, then alphabetical order. |
|
|
Defines the roles file and overrides the default |
|
|
Defines the networks file and overrides the default network_data.yaml in the |
|
|
Defines the plan Environment file and overrides the default |
|
| Do not delete temporary files after deployment and just log their location. |
|
| Update the plan. Do not perform the actual deployment. |
|
| The overcloud creation process performs a set of pre-deployment checks. This option exits if any non-fatal errors occur from the pre-deployment checks. It is advisable to use this option as any errors can cause your deployment to fail. |
|
| 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. openstack-tripleo-validations |
|
| Performs validation check on the overcloud but does not actually create the overcloud. |
|
|
Run external validations from the |
|
| Skip the overcloud post-deployment configuration. |
|
| Force the overcloud post-deployment configuration. |
|
|
Skip generation of a unique identifier for the |
|
| Path to a YAML file with arguments and parameters. |
|
| Disable password generation for the overcloud services. |
|
|
Use pre-provisioned overcloud nodes. Used in conjunction with |
|
|
Disable the |
|
|
Disable the overcloud stack creation and only run the |
|
|
Directory to use for saved |
|
|
Path to Ansible configuration file. The configuration in the file overrides any configuration that |
|
|
Timeout in minutes to use for |
|
| Register overcloud nodes to the Customer Portal or Satellite 6. |
|
|
Registration method to use for the overcloud nodes. |
|
| Organization to use for registration. |
|
| Register the system even if it is already registered. |
|
|
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 the server is a Red Hat Satellite 6 server, the overcloud obtains the |
|
| Activation key to use for registration. |
Run the following command to view a full list of options:
(undercloud) $ openstack help overcloud deploy
(undercloud) $ openstack help overcloud deploy
Some command line parameters are outdated or deprecated in favor of using Heat template parameters, which you include in the parameter_defaults section on an environment file. The following table maps deprecated parameters to their Heat Template equivalents.
| Parameter | Description | Heat Template Parameter |
|---|---|---|
|
| The number of Controller nodes to scale out |
|
|
| The number of Compute nodes to scale out |
|
|
| The number of Ceph Storage nodes to scale out |
|
|
| The number of Cinder nodes to scale out |
|
|
| The number of Swift nodes to scale out |
|
|
| The flavor to use for Controller nodes |
|
|
| The flavor to use for Compute nodes |
|
|
| The flavor to use for Ceph Storage nodes |
|
|
| The flavor to use for Cinder nodes |
|
|
| The flavor to use for Swift storage nodes |
|
|
| The overcloud creation process performs a set of pre-deployment checks. This option exits if any fatal errors occur from the pre-deployment checks. It is advisable to use this option as any errors can cause your deployment to fail. | No parameter mapping |
|
|
Disable the pre-deployment validations entirely. These validations were built-in pre-deployment validations, which have been replaced with external validations from the | No parameter mapping |
|
|
Run deployment using the | No parameter mapping |
These parameters are scheduled for removal in a future version of Red Hat OpenStack Platform.
6.13. Including environment files in an overcloud deployment Copiar o linkLink copiado para a área de transferência!
Use the -e option to include an environment file to customize your overcloud. You can include as many environment files as necessary. However, the order of the environment files is important as the parameters and resources defined in subsequent environment files take precedence. Use the following list as an example of the environment file order:
- The number of nodes and the flavors for each role. It is vital to include this information for overcloud creation.
- The location of the container images for containerized OpenStack services.
Any network isolation files, starting with the initialization file (
environments/network-isolation.yaml) from the heat template collection, then your custom NIC configuration file, and finally any additional network configurations. See the following chapters in the Advanced Overcloud Customization guide for more information:- Any external load balancing environment files if you are using an external load balancer. See External Load Balancing for the Overcloud for more information.
- Any storage environment files such as Ceph Storage, NFS, iSCSI, etc.
- Any environment files for Red Hat CDN or Satellite registration.
- Any other custom environment files.
Any environment files added to the overcloud using the -e option become part of your overcloud’s stack definition.
The following command is an example of how to start the overcloud creation using environment files defined earlier in this scenario:
(undercloud) $ openstack overcloud deploy --templates \ -e /home/stack/templates/node-info.yaml \ -e /home/stack/containers-prepare-parameter.yaml \ -e /home/stack/inject-trust-anchor-hiera.yaml \ -r /home/stack/templates/roles_data.yaml
(undercloud) $ openstack overcloud deploy --templates \
-e /home/stack/templates/node-info.yaml \
-e /home/stack/containers-prepare-parameter.yaml \
-e /home/stack/inject-trust-anchor-hiera.yaml \
-r /home/stack/templates/roles_data.yaml
This command contains the following additional options:
- --templates
-
Creates the overcloud using the Heat template collection in
/usr/share/openstack-tripleo-heat-templatesas a foundation - -e /home/stack/templates/node-info.yaml
- Adds an environment file to define how many nodes and which flavors to use for each role.
- -e /home/stack/containers-prepare-parameter.yaml
- Adds the container image preparation environment file. You generated this file during the undercloud installation and can use the same file for your overcloud creation.
- -e /home/stack/inject-trust-anchor-hiera.yaml
- Adds an environment file to install a custom certificate in the undercloud.
- -r /home/stack/templates/roles_data.yaml
- (optional) The generated roles data if using custom roles or enabling a multi architecture cloud. See Section 6.7, “Creating architecture specific roles” for more information.
The director requires these environment files for re-deployment and post-deployment functions. Failure to include these files can result in damage to your overcloud.
To modify the overcloud configuration at a later stage, perform the following actions:
- Modify parameters in the custom environment files and Heat templates
-
Run the
openstack overcloud deploycommand again with the same environment files
Do not edit the overcloud configuration directly as such manual configuration gets overridden by the director’s configuration when updating the overcloud stack with the director.
6.14. Validating the overcloud configuration before deployment operations Copiar o linkLink copiado para a área de transferência!
Before executing an overcloud deployment operation, validate your Heat templates and environment files for any errors.
Procedure
The core Heat templates for the overcloud are in a Jinja2 format. To validate your templates, render a version without Jinja2 formatting using the following commands:
cd /usr/share/openstack-tripleo-heat-templates ./tools/process-templates.py -o ~/overcloud-validation
$ cd /usr/share/openstack-tripleo-heat-templates $ ./tools/process-templates.py -o ~/overcloud-validationCopy to Clipboard Copied! Toggle word wrap Toggle overflow Use the following command to validate the template syntax:
(undercloud) $ openstack orchestration template validate --show-nested \ --template ~/overcloud-validation/overcloud.yaml \ -e ~/overcloud-validation/overcloud-resource-registry-puppet.yaml \ -e [ENVIRONMENT FILE] \ -e [ENVIRONMENT FILE]
(undercloud) $ openstack orchestration template validate --show-nested \ --template ~/overcloud-validation/overcloud.yaml \ -e ~/overcloud-validation/overcloud-resource-registry-puppet.yaml \ -e [ENVIRONMENT FILE] \ -e [ENVIRONMENT FILE]Copy to Clipboard Copied! Toggle word wrap Toggle overflow The validation requires the
overcloud-resource-registry-puppet.yamlenvironment file to include overcloud-specific resources. Add any additional environment files to this command with-eoption. Also include the--show-nestedoption to resolve parameters from nested templates.- The validation command identifies any syntax errors in the template. If the template syntax validates successfully, the command returns a preview of the resulting overcloud template.
6.15. Overcloud deployment output Copiar o linkLink copiado para a área de transferência!
Once the overcloud creation completes, the director provides a recap of the Ansible plays executed to configure the overcloud:
The director also provides details to access your overcloud.
6.16. Accessing the overcloud Copiar o linkLink copiado para a área de transferência!
The director generates a script to configure and help authenticate interactions with your overcloud from the director host. The director saves this file, overcloudrc, in your stack user’s home director. Run the following command to use this file:
(undercloud) $ source ~/overcloudrc
(undercloud) $ source ~/overcloudrc
This loads environment variables necessary to interact with your overcloud from the director host’s CLI. The command prompt changes to indicate this:
(overcloud) $
(overcloud) $
To return to interacting with the director’s host, run the following command:
(overcloud) $ source ~/stackrc (undercloud) $
(overcloud) $ source ~/stackrc
(undercloud) $
Each node in the overcloud also contains a heat-admin user. The stack user has SSH access to this user on each node. To access a node over SSH, find the IP address of the desired node:
(undercloud) $ openstack server list
(undercloud) $ openstack server list
Then connect to the node using the heat-admin user and the node’s IP address:
(undercloud) $ ssh heat-admin@192.168.24.23
(undercloud) $ ssh heat-admin@192.168.24.23
6.17. Next steps Copiar o linkLink copiado para a área de transferência!
This concludes the creation of the overcloud using the command line tools. For post-creation functions, see Chapter 9, Performing overcloud post-installation tasks.