TripleO ======= .. contents:: Table of Contents Introduction ------------ Supported operating systems: RHEL/CentOS >= 7, Fedora TripleO means "OpenStack on OpenStack." The Undercloud is first deployed onto a single node with the essential OpenStack services to handle baremetal deployments. That server is then used to create and manage a full production cloud called the Overcloud. TripleO is a collection of many services. As part of the Transformation Squad's goal, Undercloud services are being removed and/or refactored to provide a simpler deployment tool. These are the services that are used on the Undercloud [52]: .. csv-table:: :header: Service, Removed In, Replaced By, Description :widths: 20, 20, 20, 20 Ansible, "", "", Used for deploying the Undercloud and Overcloud services. Ceilometer, Stein, "", Collects information about the Overcloud nodes. docker, Ussuri, Podman, Container runtime for OpenStack services. Glance, "", "", Image management used by Ironic. Gnocchi, Stein, "", A more efficient alternative to Ceilometer. Heat, "", "", Heat parameters define the deployment settings. Horizon, "Stein", "", Web dashboard for deploying an Overcloud. Ironic, "", "", Manages the bare-metal provisioning. Keystone, "", "", Authentication of OpenStack services. Kolla, Victoria, "Ansible (`TCIB `__)", Provides container images of OpenStack services. MariaDB, "", "", Database for OpenStack services. Mistral, Victoria, Ansible, Workflows are used to define and execute all of the deployment processes. Neutron, "", "", Manages the Overcloud networks. Nova, "", "", Manages the Overcloud nodes after provisioning. Paunch, Victoria, Ansible, Container state management. Podman, "", "", Container runtime for OpenStack services. Puppet, "", "", Configuration management. RabbitMQ, "", "", Messaging back-end for OpenStack services. Swift, "", "", Storage for Heat deployment plans. Zaqar, Victoria, Ansible, A messaging service used by Mistral. In Pike, most of the Overcloud services are deployed as containers built by Kolla. The most notable service that lacked container support was Neutron due to it's complexity. Starting in Queens, all of the Overcloud services are installed as containers. Support for also running the Undercloud services in containers was added as a technology preview in Queens and later became the default configuration for Rocky. Previously, `instack-undercloud `__ was used to setup and install the Undercloud services and now the same deployment method for the Overcloud is used for the Undercloud. [20] Red Hat OpenStack Platform Releases ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Red Hat provides most of the development to the core OpenStack services. The RPM Distribution of OpenStack (RDO) project is a community project lead by Red Hat to use the latest upstream code from OpenStack and package it to work and be distributable on Red Hat Enterprise Linux and Fedora based operating systems. [2] The Red Hat OpenStack Platform (RHOSP) is a solution by Red Hat that takes the upstream OpenStack source code and makes it enterprise quality by hardening the security and increasing it's stability. Upgrades from one major release of RHOSP to the next have been supported since RHOSP 8. Release Cycle: - RHOSP < 10 = Each release is supported for up to 3 years. - RHOSP >= 10 = Starting with RHOSP 10, every third release of RHOSP is a long-life (LL) release with up to 5 years of support. In-between releases are supported for 1 year. Fast-forward upgrades are supported to upgrade directly from one LL release to the next (for example, 10 to 13). - RHOSP >= 16 = Every release of RHOSP is now a LL release. [43] Releases: - RHOSP 3 (Grizzly) - Release: 2013-07-10 - EOL: 2014-07-31 - RHOSP 4 (Havana) - Release: 2013-12-19 - EOL: 2015-06-19 - RHOSP 5 (Icehouse) - Release: 2014-06-30 - EOL: 2017-06-30 - RHOSP 6 (Juno) - Release: 2015-02-09 - EOL: 2018-02-17 - RHOSP 7 (Kilo) - Release: 2015-08-05 - EOL: 2018-08-05 - RHOSP 8 (Liberty) - Release: 2016-04-20 - EOL: 2019-04-20 - RHOSP 9 (Mitaka) - Release: 2016-08-24 - EOL: 2019-08-24 - **RHOSP 10 LL (Newton)** - Release: 2016-12-15 - EOL: 2021-12-15 - RHOSP 11 (Ocata) - Release: 2017-05-18 - EOL: 2018-05-18 - RHOSP 12 (Pike) - Release: 2017-12-13 - EOL: 2018-12-13 - **RHOSP 13 LL (Queens)** - Release: 2018-06-27 - EOL: 2023-06-27 - RHOSP 14 (Rocky) - Release: 2019-01-10 - EOL: 2020-01-10 - RHOSP 15 (Stein) - Release: 2019-09-19 - EOL: 2020-09-19 - **RHOSP 16 LL (Train)** - Release: 2020-02-06 - EOL: 2025-05-30 Starting with RHOSP 16, each minor release is tied to a specific version of RHEL. [1] .. csv-table:: :header: RHOSP, RHEL :widths: 20, 20 16.0, 8.1 16.1, 8.2 16.2, 8.4 RHOSP supports running a virtualized Undercloud on these platforms [3]: - Kernel-based Virtual Machine (QEMU with KVM acceleration) - Red Hat Virtualization (RHV) - Microsoft Hyper-V - VMware ESX and ESXi RHOSP only supports using libvirt with KVM as the compute hypervisor's virtualization technology. [28] The version of RHOSP in use can be found on the Undercloud by viewing the "/etc/rhosp-release" file. OpenStack packages can also be tracked down to which major release it is a part of by using https://access.redhat.com/downloads/content/package-browser. .. code-block:: sh $ yum install rhosp-release $ cat /etc/rhosp-release Red Hat OpenStack Platform release 16.0.1 (Train) Historical Milestones --------------------- Upstream ~~~~~~~~ - Havana - `The first release of Spinal Stack. `__ - Icehouse - `The last release of Spinal Stack. The usage of OpenStack to deploy OpenStack was used as inspiration for TripleO. `__ - Juno - TripleO (OpenStack-on-OpenStack) was released as the spiritual successor to Spinal Stack. - Mitaka - `Introduced the TripleO UI dashboard for helping to deploy an Overcloud. `__ - Ocata - `OpenStack services on the Overcloud are containerized using containers built by Kolla (except for Cinder, Manila, and Neutron). `__ - Pike - config-download (Ansible content) was created as an alternative to Heat for deploying the OpenStack services on the Overcloud. - Queens - `Introduced Fast Forward Upgrades (FFUs). The first supported FFU is from Newton straight to Queens. `__ - All OpenStack services on the Overcloud have been containerized. - Experimental support for using containerized OpenStack services on the Undercloud. - Rocky - instack-undercloud is no longer used for installing the Undercloud. The Undercloud now reuses the same workflows used by the Overcloud deploy, update, and upgrade process. - Undercloud services are now containerized by default. - `config-download is now the default deployment method. `__ - config-download now supports using ceph-ansible for managing Ceph clusters. - `Introduced Standalone deployments (an all-in-one Overcloud that does not require an Undercloud). `__ - Deprecated the TripleO UI. - Stein - `Container management can now use podman instead of docker. `__ - `Removed the TripleO UI. `__ - Train - Fast Forward Upgrade from Queens to Train. - `The first upstream release to support CentOS 8. `__ - `Minion node support for scaling the Undercloud resources for Heat and Ironic. `__ - Ussuri - `Replaced Paunch with Ansible for container management. `__ - `Removed Undercloud dependencies on Glance, Neutron, and Nova by having a Nova-less deployment process. `__ `MetalSmith `__ can now used to provision the Overcloud nodes separately from the Overcloud deployment. TripleO treats all deployments as pre-deployed servers. - `Removed Mistral and Zaqar from the Undercloud. The Overcloud deployment workflow now uses Ansible. `__ - `Provided standardized Ansible playbooks and roles for operators to manage their TripleO clouds. `__ - Victoria - Kolla container images are no longer used. `TripleO Container Image Build (TCIB) `__ is a new Ansible wrapper for creating smaller container images based on the RHEL Universal Base Image (UBI) 8 image. [57][58] Downstream ~~~~~~~~~~ - RHOSP 2 - `The first OpenStack product released by Red Hat. `__ - RHOSP 3 - The first RHOSP release to include the `Foreman OpenStack Manager `__ to automate the deployment of servers and installation of OpenStack services. - This was the first RHOSP release to have official support. - RHOSP 5 - `Introduced Packstack as an easy way to deploy a single-node proof-of-concept cloud using Puppet. `__. - `The first release to support RHEL 7 `__. - `Red Hat acquired eNovance, the company that created TripleO (previously named Spinal Stack), in June of 2014. `__ - RHOSP 6 - `Introduced TripleO as another proof-of-concept deployment tool. It uses an all-in-one OpenStack cloud (the Undercloud) to deploy a production cloud (the Overcloud). `__ - RHOSP 7 - `TripleO, now known as Director downstream and temporarily renamed to the RDO Manager upstream, replaces the Foreman OpenStack Manager as the deployment tool. `__ - RHOSP 8 - `Automated minor updates and major upgrades. `__ - RHOSP 10 - The first long-life release to receive up to 5 years of support. - RHOSP 13 - RHOSP's second long-life release. - Introduced Fast Forward Upgrade path from RHOSP 10 to 13. - RHOSP 14 - The TripleO UI has been deprecated. - RHOSP 15 - The first release to support RHEL 8. - `Telemetry services (aodh, ceilometer, and gnocchi) are deprecated in favor of the Red Hat Service Assurance Framework. `__ - RHOSP 16 - RHOSP's third long-life release. - Introduced Fast Forward Upgrade path from RHOSP 13 to 16. [1] Repositories ------------ Upstream ~~~~~~~~ The upstream TripleO project has three main repositories for each OpenStack release: .. csv-table:: :header: Name and Aliases, Testing Level, Use Case :widths: 20, 20, 20 "General Availability (GA), Release, or Tested", High, Production "Testing, Test, or Buildlogs", Medium, Pre-production "Trunk, Current, Consistent, or Untested", Low, Development If installing on RHEL, it is required to enable additional repositories: - RHEL 7 [40]: .. code-block:: sh $ sudo subscription-manager repos --disable=* $ sudo subscription-manager repos --enable rhel-7-server-rpms --enable rhel-7-server-rh-common-rpms --enable rhel-7-server-extras-rpms - RHEL 8 [74]: .. code-block:: sh $ sudo subscription-manager repos --disable=* $ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-eus-rpms --enable=rhel-8-for-x86_64-appstream-eus-rpms --enable=rhel-8-for-x86_64-highavailability-eus-rpms --enable=ansible-2-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms If installing on CentOS 8, it is required to enable both the high availability (for Pacemaker packages) and PowerTools (for Ruby packages) repositories. .. code-block:: sh $ sudo dnf config-manager --set-enabled HighAvailability $ sudo dnf config-manager --set-enabled PowerTools - **GA**: - CentOS: .. code-block:: sh $ sudo yum install centos-release-openstack-${OPENSTACK_RELEASE} - RHEL: .. code-block:: sh $ sudo yum install https://repos.fedorapeople.org/repos/openstack/openstack-${OPENSTACK_RELEASE}/rdo-release-${OPENSTACK_RELEASE}-${RDO_RPM_RELEASE}.noarch.rpm - **Testing** - CentOS: .. code-block:: sh $ sudo yum install centos-release-openstack-${OPENSTACK_RELEASE} $ sudo yum-config-manager --enable centos-openstack-${OPENSTACK_RELEASE}-test - RHEL: .. code-block:: sh $ sudo yum install https://repos.fedorapeople.org/repos/openstack/openstack-${OPENSTACK_RELEASE}/rdo-release-${OPENSTACK_RELEASE}-${RDO_RPM_RELEASE}.noarch.rpm $ sudo yum-config-manager --enable openstack-${OPENSTACK_RELEASE}-testing - **Trunk** - Trunk builds are divided into different stages [54][65]: - current = The latest individually successfully built packages from every RDO and OpenStack project. - consistent = The ``current`` build passed the tripleo-ci promotion jobs. - current-tripleo = The ``consistent`` build passed phase 1 CI promotion jobs. - current-tripleo-rdo = The ``current-tripleo`` build passed `phase 2 CI promotion jobs `__. This is also known as ``current-passed-ci`` because it has passed all of the available CI jobs. - RDO repository (current-tripleo-rdo): .. code-block:: sh $ sudo yum install https://repos.fedorapeople.org/repos/openstack/openstack-${OPENSTACK_RELEASE}/rdo-release-${OPENSTACK_RELEASE}-${RDO_RPM_RELEASE}.noarch.rpm $ sudo yum-config-manager --enable rdo-trunk-${OPENSTACK_RELEASE}-tested - Or ``tripleo-repos`` [22]: - CentOS 7 (<= Train): .. code-block:: sh $ sudo yum install "https://trunk.rdoproject.org/centos7/current-tripleo-rdo/$(curl -k https://trunk.rdoproject.org/centos7/current-tripleo-rdo/ | grep python2-tripleo-repos- | cut -d\" -f8)" - CentOS 8 (>= Train): .. code-block:: sh $ sudo yum install "https://trunk.rdoproject.org/centos8-${OPENSTACK_RELEASE}/component/tripleo/current-tripleo-rdo/$(curl -k https://trunk.rdoproject.org/centos8-${OPENSTACK_RELEASE}/component/tripleo/current-tripleo-rdo/ | grep "python3-tripleo-repos" | cut -d\" -f8)" - Setup the TripleO repositories: .. code-block:: sh $ sudo tripleo-repos -b ${OPENSTACK_RELEASE} current-tripleo-rdo - Or manually: .. code-block:: sh $ EL_VER="8" $ sudo curl -L -o /etc/yum.repos.d/delorean-${OPENSTACK_RELEASE}.repo https://trunk.rdoproject.org/centos${EL_VER}-${OPENSTACK_RELEASE}/current-tripleo-rdo/delorean.repo $ sudo curl -L -o /etc/yum.repos.d/delorean-deps-${OPENSTACK_RELEASE}.repo https://trunk.rdoproject.org/centos${EL_VER}-${OPENSTACK_RELEASE}/delorean-deps.repo - Create a container image prepare file that uses the ``current-tripleo`` (default), ``current-tripleo-rdo``, or a Delorean hash tag. Container images are not built for ``current``. Configure the ``undercloud.conf`` to use this file via the ``container_images_file`` parameter. Configure the Overcloud to use it by adding it as another Heat environment template: ``openstack overcloud deploy --templates -e ~/containers-prepare-parameters.yaml``. [76] .. code-block:: sh $ openstack tripleo container image prepare default --output-env-file ~/containers-prepare-parameters.yaml $ ${EDITOR} ~/containers-prepare-parameters.yaml .. code-block:: yaml --- parameter_defaults: ContainerImagePrepare: - set: namespace: docker.io/tripleo tag: current-tripleo-rdo # Alternatively, to prevent unforeseen updates, the tag can be a Delorean hash. # For example, for # https://trunk.rdoproject.org/centos8-victoria/current-tripleo-rdo/7f/97/7f974e10d7184d5fc45445a3073333bd/ # this tag can be used: #namespace: docker.io/tripleovictoria #tag: 7f974e10d7184d5fc45445a3073333bd [53] Downstream ~~~~~~~~~~ It is recommended to disable any existing repositories to avoid package conflicts. .. code-block:: sh $ sudo subscription-manager repos --disable=* - RHOSP 10 [26]: .. code-block:: sh $ 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-nfv-rpms --enable=rhel-7-server-rhceph-2-tools-rpms --enable=rhel-7-server-rhceph-2-mon-rpms --enable=rhel-7-server-rhceph-2-osd-rpms --enable=rhel-7-server-openstack-10-rpms - RHOSP 13 [27]: .. code-block:: sh $ 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-nfv-rpms --enable=rhel-7-server-rhceph-3-tools-rpms --enable=rhel-7-server-rhceph-3-mon-rpms --enable=rhel-7-server-rhceph-3-osd-rpms --enable=rhel-7-server-openstack-13-rpms - RHOSP 16 [55]: .. code-block:: sh $ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms --enable=rhel-8-for-x86_64-appstream-rpms --enable=rhel-8-for-x86_64-highavailability-rpms --enable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=openstack-16-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms Deployment (Quick) ------------------ Packstack ~~~~~~~~~ Supported operating system: RHEL/CentOS 7, Fedora Packstack is part of Red Hat's RDO project. It's purpose is for providing small and simple demonstrations of OpenStack. This tool does not handle any upgrades of the OpenStack services. Hardware requirements [9]: - 16GB RAM Install ^^^^^^^ Disable NetworkManager. It is not compatible with Packstack. .. code-block:: sh $ sudo systemctl disable NetworkManager Install the Packstack utility. .. code-block:: sh $ sudo yum -y install openstack-packstack There are two network scenarios that Packstack can deploy. The default is to have an isolated network (1). Floating IPs will not be able to access the network on the public interface. For lab environments, Packstack can also configure Neutron to expose the network instead to allow instances with floating IPs to access other IP addresses on the network (2). ``1.`` Isolated Network Install Generate a configuration file referred to as the "answer" file. This can optionally be customized. Then install OpenStack using the answer file. By default, the network will be entirely isolated. [4] .. code-block:: sh $ sudo packstack --gen-answer-file $ sudo packstack --answer-file Packstack logs are stored in /var/tmp/packstack/. The administrator and demo user credentials will be saved to the user's home directory. .. code-block:: sh $ source ~/keystonerc_admin $ source ~/keystonerc_demo Although the network will not be exposed by default, it can still be configured later. The primary interface to the lab's network, typically ``eth0``, will need to be configured as a Open vSwitch bridge to allow this. Be sure to replace the "IPADDR", "PREFIX", and "GATEWAY" with the server's correct settings. Neutron will also need to be configured to allow "flat" networks. File: /etc/sysconfig/network-scripts/ifcfg-eth0 :: DEVICE=eth0 ONBOOT=yes DEVICETYPE=ovs TYPE=OVSPort OVS_BRIDGE=br-ex BOOTPROTO=none NM_CONTROLLED=no File: /etc/sysconfig/network-scripts/ifcfg-br-ex :: DEVICE=br-ex ONBOOT=yes DEVICETYPE=ovs TYPE=OVSBridge DEFROUTE=yes IPADDR=192.168.1.200 PREFIX=24 GATEWAY=192.168.1.1 PEERDNS=no BOOTPROTO=none NM_CONTROLLED=no ``2.`` Exposed Network Install It is also possible to deploy OpenStack where Neutron can have access to the public network. Run the Packstack installation with the command below and replace "eth0" with the public interface name. .. code-block:: sh $ sudo packstack --allinone --provision-demo=n --os-neutron-ovs-bridge-mappings=extnet:br-ex --os-neutron-ovs-bridge-interfaces=br-ex:eth0 --os-neutron-ml2-type-drivers=vxlan,flat Alternatively, use these configuration options in the answer file. .. code-block:: ini CONFIG_NEUTRON_ML2_TYPE_DRIVERS=vxlan,flat CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=extnet:br-ex CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-ex:eth0 CONFIG_PROVISION_DEMO=n .. code-block:: sh $ sudo packstack --answer-file After the installation is finished, create the necessary network in Neutron as the admin user. In this example, the network will automatically allocate IP addresses between 192.168.1.201 and 192.168.1.254. The IP 192.168.1.1 is both the physical router and default gateway. .. code-block:: sh $ . keystonerc_admin $ openstack network create --share --provider-physical-network physical_network --provider-network-type flat --router external external_network $ openstack subnet create --subnet-range 192.168.1.0/24 --gateway 192.168.1.1 --network external_network --allocation-pool start=192.168.1.201,end=192.168.1.254 --no-dhcp public_subnet The "external\_network" can now be associated with a router in user accounts. [5][90] Answer File ^^^^^^^^^^^ The "answer" configuration file defines how OpenStack should be setup and installed. Using a answer file can provide a more customizable deployment. Common options: - CONFIG\_DEFAULT\_PASSWORD = Any blank passwords in the answer file will be set to this value. - CONFIG\_KEYSTONE\_ADMIN\_TOKEN = The administrator authentication token. - CONFIG\_KEYSTONE\_ADMIN\_PW = The administrator password. - CONFIG\_MARIADB\_PW = The MariaDB root user's password. - CONFIG\_HORIZON\_SSL = Configure an SSL for the Horizon dashboard. This requires that SSLs be generated manually and then defined in the configuration file [6]: :: $ for cert in selfcert ssl_dashboard ssl_vnc; do sudo openssl req -x509 -sha256 -newkey rsa:2048 -keyout /etc/pki/tls/private/${cert}.key -out /etc/pki/tls/certs/${cert}.crt -days 365 -nodes; done - CONFIG\_SSL\_CACERT\_FILE=/etc/pki/tls/certs/selfcert.crt - CONFIG\_SSL\_CACERT\_KEY\_FILE=/etc/pki/tls/private/selfkey.key - CONFIG\_VNC\_SSL\_CERT=/etc/pki/tls/certs/ssl\_vnc.crt - CONFIG\_VNC\_SSL\_KEY=/etc/pki/tls/private/ssl\_vnc.key - CONFIG\_HORIZON\_SSL\_CERT=/etc/pki/tls/certs/ssl\_dashboard.crt - CONFIG\_HORIZON\_SSL\_KEY=/etc/pki/tls/private/ssl\_dashboard.key - CONFIG\_HORIZON\_SSL\_CACERT=/etc/pki/tls/certs/selfcert.crt - CONFIG__INSTALL = Install a specific OpenStack service. - CONFIG__HOST = The host to setup the relevant services on. - CONFIG__HOSTS = A list of hosts to setup the relevant services on. This currently only exists for "COMPUTE" and "NETWORK." New hosts can be added and Packstack re-run to have them added to the OpenStack cluster. - CONFIG\_PROVISION\_DEMO = Setup a demo project and user account with an image and network configured. Uninstall ^^^^^^^^^ For uninstalling everything that is installed by Packstack, run `this Bash script `__ on all of the OpenStack nodes. Use at your own risk. TripleO Quickstart ~~~~~~~~~~~~~~~~~~ The TripleO Quickstart project was created to use Ansible to automate deploying a TripleO Undercloud and Overcloud. [7] The project recommends a minimum of 32GB RAM and 120GB of disk space when deploying with the default settings. [9] This deployment has to use a baremetal hypervisor. Deploying TripleO within a virtual machine that uses nested virtualization is not supported. [10] - Download the tripleo-quickstart script or clone the entire repository from OpenDev or GitHub. .. code-block:: sh $ curl -O https://opendev.org/openstack/tripleo-quickstart/raw/branch/master/quickstart.sh OR .. code-block:: sh $ git clone https://opendev.org/openstack/tripleo-quickstart.git $ cd tripleo-quickstart - Install dependencies for the quickstart script. .. code-block:: sh $ sudo bash quickstart.sh --install-deps TripleO can now be installed automatically with the default setup of 3 virtual machines. This will be created to meet the minimum TripleO cloud requirements: (1) an Undercloud to deploy a (2) controller and (3) compute node. [8] . Otherwise, a different node configuration from "config/nodes/" can be specified or created. Common node variables: - {block\|ceph\|compute\|control\|default\|objectstorage\|undercloud}\_{memory\|vcpu} = Define the amount of processor cores or RAM (in megabytes) to allocate to the respective virtual machine type. Use "default" to apply to all nodes that are not explicitly defined. Further customizations should be configured now before deploying the TripleO environment. Refer to the `Undercloud Deploy role's documentation `__ on all of the Ansible variables for the Undercloud. Add any override variables to a YAML file and then add the arguments ``-e @.yaml`` to the "quickstart.sh" commands. ``1.`` Automatic - Run the quickstart script to install TripleO. Use "127.0.0.2" for the localhost IP address if TripleO will be installed on the same system that the quickstart command is running on. .. code-block:: sh $ bash quickstart.sh --release trunk/queens --tags all [7] ``2.`` Manual - Common quickstart.sh options: - ``--clean`` = Remove previously created files from the working directory on the start of TripleO Quickstart. - ``--extra-vars supported_distro_check=false`` = Run on an unsupported hypervisor such as Fedora. - ``--no-clone`` = Use the current working directory for TripleO Quickstart. This should only be if the entire repository has been cloned. - ``--nodes config/nodes/.yml`` = Specify the configuration that determines how many Overcloud nodes should be deployed. - ``--playbook`` = Specify a Playbook to run. - ``--release`` = The OpenStack release to use. All of the available releases can be found in the OpenDev or GitHub project in the "config/release/" directory. Use "trunk/````" for the development version and "stable/````" for the stable version. - ``--retain-inventory`` = Use the existing inventory. This is useful for managing an existing TripleO Quickstart infrastructure. - ``--teardown {all|nodes|none|virthost}`` = Delete everything related to TripleO (all), only the virtual machines (nodes), nothing (none), or the virtual machines and settings on the hypervisor (virthost). - ``--tags all`` = Deploy a complete all-in-one TripleO installation automatically. If a Playbook is specified via ``-p``, then everything in that Playbook will run. - ``-v`` = Show verbose output from the Ansible playbooks. - ``--config=~/.quickstart/config/general_config/containers_minimal.yml`` = Deploy the Overcloud from Kolla docker containers. [20] -------------- - Setup the Undercloud virtual machine. .. code-block:: sh $ bash quickstart.sh --release trunk/queens --clean --teardown all --tags all --playbook quickstart.yml - Install the Undercloud services. .. code-block:: sh $ bash quickstart.sh --release trunk/queens --teardown none --no-clone --tags all --retain-inventory --playbook quickstart-extras-undercloud.yml - Setup the Overcloud virtual machines. .. code-block:: sh $ bash quickstart.sh --release trunk/queens --teardown none --no-clone --tags all --nodes config/nodes/1ctlr_1comp.yml --retain-inventory --playbook quickstart-extras-overcloud-prep.yml - Install the Overcloud services. .. code-block:: sh $ bash quickstart.sh --release trunk/queens --teardown none --no-clone --tags all --nodes config/nodes/1ctlr_1comp.yml --retain-inventory --playbook quickstart-extras-overcloud.yml - Validate the installation. .. code-block:: sh $ bash quickstart.sh --release trunk/queens --teardown none --no-clone --tags all --nodes config/nodes/1ctlr_1comp.yml --retain-inventory --playbook quickstart-extras-validate.yml [11] Standalone ~~~~~~~~~~ Requirements: - 4 CPU cores - 8GB RAM - 50GB storage OpenStack services: - Cinder - Glance - Keystone - Neutron - Nova - Placement - Swift Starting with Rocky, an all-in-one Overcloud can be deployed without the need of an Undercloud. This is known as a Standalone deployment. It can be used for proof-of-concept TripleO deployments or for developers as an alternative to `devstack `__. It is possible to deploy more than one Overcloud node using this method and to scale-up to more nodes at a later date. Although possible in upstream TripleO, in RHOSP this is unsupported by Red Hat. The process is almost exactly the same as an Undercloud deployment. It deploys a fully functional Overcloud onto the local server. Unlike a typical Overcloud deployment (before the Victoria release where Mistral was removed), Mistral is not used. Instructions on how to setup a Standalone cloud are documented `here `__. After the installation, the config-download Ansible playbooks will be available in the home directory as ``undercloud-ansible-``. By default, some services, such as Heat, are disabled. Use this template to re-enable it. .. code-block:: yaml --- resource_registry: OS::TripleO::Services::HeatApi: /usr/share/openstack-tripleo-heat-templates/deployment/heat/heat-api-container-puppet.yaml OS::TripleO::Services::HeatApiCfn: /usr/share/openstack-tripleo-heat-templates/deployment/heat/heat-api-cfn-container-puppet.yaml OS::TripleO::Services::HeatApiCloudwatch: /usr/share/openstack-tripleo-heat-templates/deployment/heat/heat-api-cloudwatch-disabled-puppet.yaml OS::TripleO::Services::HeatEngine: /usr/share/openstack-tripleo-heat-templates/deployment/heat/heat-engine-container-puppet.yaml **Updates** These steps apply to both Undercloud and Standalone cloud deployments. - Update: .. code-block:: sh $ openstack {undercloud install|tripleo deploy} --force-stack-update - Upgrade: .. code-block:: sh $ openstack {undercloud|tripleo} upgrade - Reinstall: .. code-block:: sh $ openstack {undercloud install|tripleo deploy} --force-stack-create [48] InfraRed 2 ~~~~~~~~~~ InfraRed uses Ansible playbooks to automate deploying downstream RHOSP packages and upstream RDO packages. Install InfraRed into a Python 2 virtual environment. .. code-block:: shell $ virtualenv ~/venv_infrared $ source ~/venv_infrared/bin/activate $ git clone https://github.com/redhat-openstack/infrared.git $ cd infrared $ pip2 install --user . As of 2019, these are the officially supported plugins in InfraRed. - provision - beaker - docker - foreman - openstack - virsh - install - build-packages - cloud-config - containers-sanity - install-ceph - oooq - packstack - patch-components - tripleo-overcloud - tripleo-standalone - tripleo-undercloud - test - browbeat - bzaf - gabbi - jordan - openstack-coverage - ospdui - pytest-runner - rally - robot - tempest - tripleo-config-changes - tripleo-post-tests - other - collect-logs - dellemc-idrac - list-builds Use the ``infrared plugin search`` command to view the GitHub URL of each plugin. Then use ``infrared plugin add `` to install the plugin. Alternatively, install plugins from the working directory of the ``infrared`` repository. Install a provision plugin, such as virsh, along with the required plugins for deploying and managing a TripleO cloud. .. code-block:: shell $ infrared plugin add plugins/virsh $ infrared plugin add plugins/tripleo-undercloud $ infrared plugin add plugins/tripleo-overcloud $ infrared plugin add plugins/cloud-config - Optionally create an answers file manually or by using the CLI and then import it. Otherwise, use the CLI arguments. .. code-block:: shell $ infrared virsh --from-file=virsh_prov.ini - [virsh] - **host-address** = Required argument. Edit with any value, OR override with CLI: --host-address=