Deploys a TripleO overcloud from an existing undercloud
Run is broken into the following stages. Omitting any of the flags (or setting it to
no) will skip that stage
--introspectthe overcloud nodes
--tagovercloud nodes with proper flavors
--deployovercloud of given
--postinstallation steps (like creating a public network - see below)
--version: TripleO release to install.
- Accepts either an integer for RHEL-OSP release, or a community release
Newton, etc...) for RDO release
- The following options define the number of nodes in the overcloud:
--storage-nodes. If not provided, will try to evaluate the exiting nodes and default to
--overcloud-ssl: Boolean. Enable SSL for the overcloud services.
--overcloud-debug: Boolean. Enable debug mode for the overcloud services.
--overcloud-templates: Add extra environment template files or custom templates
to “overcloud deploy” command. Format:
--- tripleo_heat_templates: - /usr/share/openstack-tripleo-heat-templates/environments/services/sahara.yaml
--- tripleo_heat_templates:  custom_templates: parameter_defaults: NeutronOVSFirewallDriver: openvswitch
--overcloud-script: Customize the script that will deploy the overcloud.
A path to a
openstack overcloud deploycommand. This is for advance users.
--heat-templates-basedir: Allows to override the templates base dir
to be used for deployment. Default value: “/usr/share/openstack-tripleo-heat-templates”
Overcloud Public Network¶
--public-network: Bool. Whether to have infrared create a public network on the overcloud.
- Path to file containing different values for the subnet of the network above.
- Set this to
yesif overcloud’s external network is on a VLAN that’s unreachable from the undercloud. This will configure network access from UnderCloud to overcloud’s API/External(floating IPs) network, creating a new VLAN interface connected to ovs’s
br-ctlplanebridge. |NOTE: If your UnderCloud’s network is already configured properly, this could disrupt it, making overcloud API unreachable For more details, see: VALIDATING THE OVERCLOUD
no, the overcloud will deploy and manage the storage nodes. If
yesthe overcloud will connect to an external, per-existing storage service.
- The type of storage service used as backend.
- Storage configuration (YAML) file.
InfraRed allows to use custom roles to deploy overcloud. Check the Composable roles page for details.
Before Overcloud upgrade you need to perform upgrade of Undercloud
Upgrade will detect Undercloud version and will upgrade Overcloud to the same version.
--upgrade: Bool If yes, the overcloud will be upgraded.
infrared tripleo-overcloud -v --upgrade yes --deployment-files virt
--updateto: target build to upgrade to
infrared tripleo-overcloud -v --upgrade yes --updateto 2017-05-30.1 --deployment-files virt
Upgrade is assuming that Overcloud Deployment script and files/templates, which were used during the initial deployment are available at Undercloud node in home directory of Undercloud user. Deployment script location is assumed to be “~/overcloud_deploy.sh”
Before Overcloud update it’s recommended to update Undercloud
InfraRed supports minor updates from OpenStack 9
Minor update detects Undercloud’s version and updates packages within same version to latest available.
--updateto: target build to update to defaults to
None, in which case, update is disabled. possible values: build-date,
z3and all other labels supported by
rhos-releaseWhen specified, rhos-release repos would be setup and used for minor updates.
infrared tripleo-overcloud -v --updateto latest --deployment-files virt
Minor update expects that Overcloud Deployment script and files/templates, used during the initial deployment, are available at Undercloud node in home directory of Undercloud user. Deployment script location is assumed to be “~/overcloud_deploy.sh”
--buildmods: Let you the option to add flags to rhos-release:
pin- Pin puddle (dereference ‘latest’ links to prevent content from changing). This flag is selected by default
flea- Enable flea repos.
unstable- This will enable brew repos or poodles (in old releases).
none- Use none of those flags.
--buildmodsflag is for internal Red Hat usage.