diff --git a/doc/source/user/quickstart.rst b/doc/source/user/quickstart.rst index 38517f87d6..f3abf5100a 100644 --- a/doc/source/user/quickstart.rst +++ b/doc/source/user/quickstart.rst @@ -5,10 +5,16 @@ Quick Start =========== This guide provides step by step instructions to deploy OpenStack using Kolla -and Kolla-Ansible on bare metal servers or virtual machines. +on bare metal servers or virtual machines. + +Recommended reading +~~~~~~~~~~~~~~~~~~~ + +It's beneficial to learn basics of both `Ansible `__ +and `Docker `__ before running Kolla-Ansible. Host machine requirements -========================= +~~~~~~~~~~~~~~~~~~~~~~~~~ The host machine must satisfy the following minimum requirements: @@ -20,96 +26,41 @@ The host machine must satisfy the following minimum requirements: Root access to the deployment host machine is required. -Recommended environment -======================= - -This guide recommends using a bare metal server or a virtual machine. Follow -the instructions in this document to get started with deploying OpenStack on -bare metal or a virtual machine with Kolla. - -If developing Kolla on a system that provides VirtualBox or Libvirt in addition -to Vagrant, use the Vagrant virtual environment documented in -`Development Environment with Vagrant `_. - -Prerequisites -============= - -Verify the state of network interfaces. If using a VM spawned on -OpenStack as the host machine, the state of the second interface will be DOWN -on booting the VM. - -:: - - ip addr show - -Bring up the second network interface if it is down. - -:: - - ip link set ens4 up - -Verify if the second interface has an IP address. - -:: - - ip addr show - Install dependencies -==================== - -Kolla builds images which are used by Kolla-Ansible to deploy OpenStack. The -deployment is tested on CentOS, Oracle Linux and Ubuntu as both container OS -platforms and bare metal deployment targets. - -.. note:: Install is *very* sensitive about version of components. Please - review carefully because default Operating System repos are likely out of - date. - -Dependencies for the stable/ocata branch are: - -===================== =========== =========== ========================= -Component Min Version Max Version Comment -===================== =========== =========== ========================= -Ansible 2.0.0 none On deployment host -Docker 1.10.0 none On target nodes -Docker Python 1.8.1 none On target nodes -Python Jinja2 2.8.0 none On deployment host -===================== =========== =========== ========================= - -Dependencies since pike (including master branch) are: - -===================== =========== =========== ========================= -Component Min Version Max Version Comment -===================== =========== =========== ========================= -Ansible 2.2.0 none On deployment host -Docker 1.10.0 none On target nodes -Docker Python 2.0.0 none On target nodes -Python Jinja2 2.8.0 none On deployment host -===================== =========== =========== ========================= +~~~~~~~~~~~~~~~~~~~~ Make sure the ``pip`` package manager is installed and upgraded to the latest -before proceeding: +before proceeding. + +For CentOS, run: :: - #CentOS yum install epel-release yum install python-pip pip install -U pip - #Ubuntu +For Ubuntu, run: + +:: + apt-get update apt-get install python-pip pip install -U pip -Install dependencies needed to build the code with ``pip`` package manager. +To build the code with ``pip`` package manager, install the following +dependencies: + +For CentOS, run: :: - #CentOS yum install python-devel libffi-devel gcc openssl-devel libselinux-python - #Ubuntu +For Ubuntu, run: + +:: + apt-get install python-dev libffi-dev gcc libssl-dev python-selinux Kolla deploys OpenStack using `Ansible `__. Install @@ -137,7 +88,9 @@ installed using: pip install -U ansible -.. note:: It is recommended to use virtualenv to install non-system packages. +.. note:: + + It is recommended to use virtualenv to install non-system packages. If DEB based systems include a version of Ansible that meets Kolla's version requirements it can be installed by: @@ -146,200 +99,59 @@ requirements it can be installed by: apt-get install ansible -.. WARNING:: - - Kolla uses `Python Build Reasonableness (PBR) `_ - in its implementation. ``PBR`` provides version information to Kolla about - the package in use. This information is later used when building images to - specify the Docker tag used in the image built. When installing the Kolla - package via pip, ``PBR`` will always use the ``PBR`` version information. - When obtaining a copy of the software via git, ``PBR`` will use the git - version information, but **ONLY** if Kolla has not been pip installed via - the pip package manager. This is why there is an operator workflow and a - developer workflow. - -The following dependencies can be installed by bootstraping the host machine -as described in the `Automatic host bootstrap`_ section. For manual -installation, follow the instructions below: - -Since Docker is required to build images as well as be present on all deployed -targets, the Kolla community recommends installing the official Docker, Inc. -packaged version of Docker for maximum stability and compatibility with the -following command: +It's beneficial to add the following options to ansible +configuration file ``/etc/ansible/ansible.cfg``: :: - curl -sSL https://get.docker.io | bash + [defaults] + host_key_checking=False + pipelining=True + forks=100 -This command will install the most recent stable version of Docker, but please -note that Kolla releases are not in sync with Docker in any way, so some things -could stop working with new version. The latest release of Kolla is tested to -work with docker-engine>=1.10.0,!=1.13.0. To check your Docker version run this -command: - -:: - - docker --version - -When running with systemd, setup docker-engine with the appropriate information -in the Docker daemon to launch with. This means setting up the following -information in the ``docker.service`` file. If you do not set the MountFlags -option correctly then ``kolla-ansible`` will fail to deploy the -``neutron-dhcp-agent`` container and throws APIError/HTTPError. After adding -the drop-in unit file as follows, reload and restart the Docker service: - -:: - - # Create the drop-in unit directory for docker.service - mkdir -p /etc/systemd/system/docker.service.d - - # Create the drop-in unit file - tee /etc/systemd/system/docker.service.d/kolla.conf <<-'EOF' - [Service] - MountFlags=shared - EOF - -Restart Docker by executing the following commands: - -:: - - # Run these commands to reload the daemon - systemctl daemon-reload - systemctl restart docker - -On the target hosts you also need to install the latest version of the Docker -python libraries with pip: - -:: - - pip install -U docker - - -OpenStack, RabbitMQ, and Ceph require all hosts to have matching times to -ensure proper message delivery. In the case of Ceph, it will complain if the -hosts differ by more than 0.05 seconds. Some OpenStack services have timers as -low as 2 seconds by default. For these reasons it is highly recommended to -setup an NTP service of some kind. While ``ntpd`` will achieve more accurate -time for the deployment if the NTP servers are running in the local deployment -environment, `chrony `_ is more accurate when -syncing the time across a WAN connection. When running Ceph it is recommended -to setup ``ntpd`` to sync time locally due to the tight time constraints. - -To install, start, and enable ntp on CentOS execute the following: - -:: - - # CentOS 7 - yum install ntp - systemctl enable ntpd.service - systemctl start ntpd.service - -To install and start on Debian based systems execute the following: - -:: - - apt-get install ntp - -Libvirt is started by default on many operating systems. Please disable -``libvirt`` on any machines that will be deployment targets. Only one copy of -libvirt may be running at a time. - -:: - - # CentOS 7 - systemctl stop libvirtd.service - systemctl disable libvirtd.service - - # Ubuntu - service libvirt-bin stop - update-rc.d libvirt-bin disable - -On Ubuntu, apparmor will sometimes prevent libvirt from working. - -:: +Install Kolla +~~~~~~~~~~~~~ - /usr/sbin/libvirtd: error while loading shared libraries: - libvirt-admin.so.0: cannot open shared object file: Permission denied +Install Kolla for deployment or evaluation +------------------------------------------ -If you are seeing the libvirt container fail with the error above, disable the -libvirt profile. +Install kolla-ansible and its dependencies using ``pip``. :: - sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd - - -.. note:: - - On Ubuntu 16.04, please uninstall lxd and lxc packages. (An issue exists - with cgroup mounts, mounts exponentially increasing when restarting - container). - -Additional steps for upstart and other non-systemd distros -========================================================== - -For other non-systemd distros, run the following. - -:: + pip install kolla-ansible - mount --make-shared /run - mount --make-shared /var/lib/nova/mnt +Copy ``globals.yml`` and ``passwords.yml`` to ``/etc/kolla`` directory. -If /var/lib/nova/mnt is not present, do the workaround below. +For CentOS, run: :: - mkdir -p /var/lib/nova/mnt /var/lib/nova/mnt1 - mount --bind /var/lib/nova/mnt1 /var/lib/nova/mnt - mount --make-shared /var/lib/nova/mnt + cp -r /usr/share/kolla-ansible/etc_examples/kolla /etc/kolla/ -For mounting /run and /var/lib/nova/mnt as shared upon startup, edit -/etc/rc.local to add the following. +For Ubuntu, run: :: - mount --make-shared /run - mount --make-shared /var/lib/nova/mnt - -.. note:: - - If CentOS/Fedora/OracleLinux container images are built on an Ubuntu host, - the back-end storage driver must not be AUFS (see the known issues in - `Building Container Images`_). - -Install Kolla for deployment or evaluation -========================================== - -Install kolla-ansible and its dependencies using pip. - -:: + cp -r /usr/local/share/kolla-ansible/etc_examples/kolla /etc/kolla/ - pip install kolla-ansible +Copy the ``all-in-one`` and ``multinode`` inventory files to +the current directory. -Copy the configuration files globals.yml and passwords.yml to /etc directory. +For CentOS, run: :: - #CentOS - cp -r /usr/share/kolla-ansible/etc_examples/kolla /etc/kolla/ - - #Ubuntu - cp -r /usr/local/share/kolla-ansible/etc_examples/kolla /etc/kolla/ + cp /usr/share/kolla-ansible/ansible/inventory/* . -The inventory files (all-in-one and multinode) are located in -/usr/local/share/kolla-ansible/ansible/inventory. Copy the configuration files -to the current directory. +For Ubuntu, run: :: - #CentOS - cp /usr/share/kolla-ansible/ansible/inventory/* . - - #Ubuntu cp /usr/local/share/kolla-ansible/ansible/inventory/* . Install Kolla for development -============================= +----------------------------- Clone the Kolla and Kolla-Ansible repositories from git. @@ -348,331 +160,307 @@ Clone the Kolla and Kolla-Ansible repositories from git. git clone https://github.com/openstack/kolla git clone https://github.com/openstack/kolla-ansible -Kolla-ansible holds configuration files (globals.yml and passwords.yml) in -etc/kolla. Copy the configuration files to /etc directory. +Kolla-ansible holds the configuration files (``globals.yml`` and +``passwords.yml``) in ``etc/kolla``. Copy the configuration +files to ``/etc/kolla`` directory. :: cp -r kolla-ansible/etc/kolla /etc/kolla/ -Kolla-ansible holds the inventory files (all-in-one and multinode) in -ansible/inventory. Copy the configuration files to the current directory. +Kolla-ansible holds the inventory files (``all-in-one`` and ``multinode``) +in ``ansible/inventory``. Copy the inventory files to the current +directory. :: cp kolla-ansible/ansible/inventory/* . -Local Registry -============== -A local registry is recommended but not required for an ``all-in-one`` -installation when developing for master. Since no master images are available -on docker hub, the docker cache may be used for all-in-one deployments. When -deploying multinode, a registry is strongly recommended to serve as a single -source of images. Reference the -`Multinode Deployment of Kolla `_ -for more information on using a local Docker registry. -Otherwise, the `Docker Hub Image Registry`_ contains all -images from each of Kolla’s major releases. The latest release tag is 5.0.0 for -Pike. +Prepare initial configuration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Automatic host bootstrap -======================== +Inventory +--------- -Edit the ``/etc/kolla/globals.yml`` file to configure interfaces. - -:: +Next step is to prepare our inventory file. Inventory is an ansible file where +we specify node roles and access credentials. - network_interface: "ens3" - neutron_external_interface: "ens4" +Kolla-Ansible comes with ``all-in-one`` and ``multinode`` example inventory +files. Difference between them is that the former is ready for deploying +single node OpenStack on localhost. If you need to use separate host or more +than one node, edit ``multinode`` inventory: -Generate passwords. This will populate all empty fields in the -``/etc/kolla/passwords.yml`` file using randomly generated values to secure the -deployment. Optionally, the passwords may be populated in the file by hand. +Edit the first section of ``multinode`` with connection details of your environment, +for example: :: - kolla-genpwd + [control] + 10.0.0.[10:12] ansible_user=ubuntu ansible_password=foobar ansible_become=true + # Ansible supports syntax like [10:12] - that means 10, 11 and 12. + # Become clausule means "use sudo". -To quickly prepare hosts, playbook bootstrap-servers can be used. This is an -Ansible playbook which works on Ubuntu 16.04 and CentOS 7 hosts to -install and prepare the cluster for OpenStack installation. + [network:children] + control + # when you specify group_name:children, it will use contents of group specified. -:: + [compute] + 10.0.0.[13:14] ansible_user=ubuntu ansible_password=foobar ansible_become=true - kolla-ansible -i <> bootstrap-servers + [monitoring] + 10.0.0.10 + # This group is for monitoring node. + # Fill it with one of the controllers' IP address or some others. -Build container images -====================== + [storage:children] + compute -When running with systemd, edit the file -``/etc/systemd/system/docker.service.d/kolla.conf`` -to include the MTU size to be used for Docker containers. + [deployment] + localhost ansible_connection=local become=true + # use localhost and sudo -:: +To learn more about inventory files, check +`Ansible documentation `_. - [Service] - MountFlags=shared - ExecStart= - ExecStart=/usr/bin/docker daemon \ - -H fd:// \ - --mtu 1400 +To confirm that our inventory is correct, run: -.. note:: +:: - Depend of your Docker version and distro, ExecStart command may be - different which may cause Docker start failures. If your docker version - is >= 1.13.0, the ``docker daemon`` is moved to ``dockerd``, and should - be used instead. The default ExecStart command for your system can be - obtained from ``/usr/lib/systemd/system/docker.service``. + ansible -m ping all .. note:: - The MTU size should be less than or equal to the MTU size allowed on the - network interfaces of the host machine. If the MTU size allowed on the - network interfaces of the host machine is 1500 then this step can be - skipped. This step is relevant for building containers. Actual openstack - services won't be affected. + Ubuntu might not come with python pre-installed. That will cause + errors in ping module. To quickly install python with ansible you + can run ``ansible -m raw -a "apt-get -y install python-dev all"`` -.. note:: +Kolla passwords +--------------- - Verify that the MountFlags parameter is configured as shared. If you do not - set the MountFlags option correctly then kolla-ansible will fail to deploy the - neutron-dhcp-agent container and throws APIError/HTTPError. +Passwords used in our deployment are stored in ``/etc/kolla/passwords.yml`` +file. All passwords are blank in this file and have to be filled either +manually or by running random password generator: -Restart Docker and ensure that Docker is running. +For deployment or evaluation, run: :: - systemctl daemon-reload - systemctl restart docker + kolla-genpwd -The Kolla community builds and pushes tested images for each tagged release of -Kolla. Pull required images with appropriate tags in target nodes. +For development, run: :: - kolla-ansible pull -i /path/to/all-in-one + cd kolla-ansible/tools + ./generate_passwords.py -View the images. +Kolla globals.yml +----------------- -:: +``globals.yml`` is the main configuration file for Kolla-Ansible. +There are a few options that are required to deploy Kolla-Ansible: - docker images +* Image options -Developers running from master are required to build container images as the -Docker Hub does not contain built images for the master branch. Reference the -`Building Container Images`_ for more advanced build configuration. + User has to specify images that are going to be used for our deployment. + In this guide `DockerHub `__ provided + pre-built images are going to be used. To learn more about building + mechanism, please refer `image building documentation + `_. -To build images using default parameters run: + Kolla provides choice of several Linux distributions in containers: -:: + - Centos + - Ubuntu + - Oraclelinux + - Debian + - RHEL - kolla-build + For newcomers, we recommend to use CentOS 7 or Ubuntu 16.04. -By default kolla-build will build all containers using CentOS as the base image -and binary installation as base installation method. To change this behavior, -please use the following parameters with kolla-build: + :: -:: + kolla_base_distro: "centos" - --base [ubuntu|centos|oraclelinux] - --type [binary|source] + Next "type" of installation needs to be configured. + Choices are: -.. note:: + binary + using repositories like apt or yum - ``--base`` and ``--type`` can be added to the above kolla-build command if - different distributions or types are desired. + source + using raw source archives, git repositories or local source directory -It is also possible to build individual container images. As an example, if the -glance images failed to build, all glance related images can be rebuilt as -follows: + .. note:: -:: + This only affects OpenStack services. Infrastructure services like Ceph are + always "binary". - kolla-build glance + .. note:: -In order to see all available parameters, run: + Source builds are proven to be slightly more reliable than binary. -:: + :: - kolla-build -h + kolla_install_type: "source" -View the images. + To use DockerHub images, the default image tag has to be overriden. Images are + tagged with release names. For example to use stable Pike images set -:: + :: - docker images + openstack_release: "pike" -.. WARNING:: + It's important to use same version of images as kolla-ansible. That + means if pip was used to install kolla-ansible, that means it's latest stable + version so ``openstack release`` should be set to pike. If git was used with + master branch, DockerHub also provides daily builds of master branch (which is + tagged as ``master``): - Mixing of OpenStack releases with Kolla releases (example, updating - kolla-build.conf to build Mitaka Keystone to be deployed with Newton Kolla) is - not recommended and will likely cause issues. + :: -Deploy Kolla -============ + openstack_release: "master" -Kolla-Ansible is used to deploy containers by using images built by Kolla. -There are two methods of deployment: *all-in-one* and *multinode*. The -*all-in-one* deployment is similar to `devstack -`__ deploy which installs all -OpenStack services on a single host. In the *multinode* deployment, OpenStack -services can be run on specific hosts. This documentation describes deploying -an *all-in-one* setup. To setup *multinode* see the -`Multinode Deployment of Kolla `_. +* Networking -.. note:: + Kolla-Ansible requires a few networking options to be set. + We need to set network interfaces used by OpenStack. - For *multinode* deployment of kolla, check if all the hostnames are - resolvable. RabbitMQ can't work with IP addresses, so we need to make - sure that all RabbitMQ cluster hosts can resolve each other's hostnames. + First interface to set is "network_interface". This is the default interface + for multiple management-type networks. -Each method is represented as an Ansible inventory file. More information on -the Ansible inventory file can be found in the Ansible `inventory introduction -`_. + :: -All variables for the environment can be specified in the files: -``/etc/kolla/globals.yml`` and ``/etc/kolla/passwords.yml``. + network_interface: "eth0" -Generate passwords for ``/etc/kolla/passwords.yml`` using the provided -``kolla-genpwd`` tool. The tool will populate all empty fields in the -``/etc/kolla/passwords.yml`` file using randomly generated values to secure the -deployment. Optionally, the passwords may be populate in the file by hand. + Second interface required is dedicated for Neutron external (or public) networks, + can be vlan or flat, depends on how the networks are created. This interface + should be active without IP address. If not, instances won't be able to access + to the external networks. -:: + :: - kolla-genpwd + neutron_external_interface: "eth1" -Start by editing ``/etc/kolla/globals.yml``. Check and edit, if needed, these -parameters: ``kolla_base_distro``, ``kolla_install_type``. The default for -``kolla_base_distro`` is ``centos`` and for ``kolla_install_type`` is -``binary``. If you want to use ubuntu with source type, then you should make -sure globals.yml has the following entries: + To learn more about network configuration, refer `Network overview + `_. -:: + Next we need to provide floating IP for management traffic. This IP will be + managed by keepalived to provide high availability, and should be set to be + *not used* address in management network that is connected to our + ``network_interface``. - kolla_base_distro: "ubuntu" - kolla_install_type: "source" + :: -Please specify an unused IP address in the network to act as a VIP for -``kolla_internal_vip_address``. The VIP will be used with keepalived and added -to the ``api_interface`` as specified in the ``globals.yml`` + kolla_internal_vip_address: "10.1.0.250" -:: +* Enable additional services - kolla_internal_vip_address: “192.168.137.79” + By default Kolla-Ansible provides a bare compute kit, however it does provide + support for a vast selection of additional services. To enable them, set + ``enable_*`` to "yes". For example, to enable Block Storage service: -.. note:: + :: - The kolla_internal_vip_address must be unique and should belong to the same - network to which the first network interface belongs to. + enable_cinder: "yes" -.. note:: + Kolla now supports many OpenStack services, there is + `a list of available services + `_. + For more information about service configuration, Please refer to the + `Services Reference Guide + `_. - The kolla_base_distro and kolla_install_type should be same as base and - install_type used in kolla-build command line. +Deployment +~~~~~~~~~~ -The ``network_interface`` variable is the interface to which Kolla binds API -services. For example, when starting Mariadb, it will bind to the IP on the -interface list in the ``network_interface`` variable. +After configuration is set, we can proceed to the deployment phase. First we +need to setup basic host-level dependencies, like docker. -:: +Kolla-Ansible provides a playbook that will install all required services in +the correct versions. - network_interface: "ens3" +* For deployment or evaluation, run: -The ``neutron_external_interface`` variable is the interface that will be used -for the external bridge in Neutron. Without this bridge the deployment instance -traffic will be unable to access the rest of the Internet. + #. Bootstrap servers with kolla deploy dependencies: -:: + :: - neutron_external_interface: "ens4" + kolla-ansible -i ./multinode bootstrap-servers -In case of deployment using the **nested** environment (eg. Using Virtualbox -VM’s, KVM VM’s), verify if your compute node supports hardware acceleration for -virtual machines by executing the following command in the *compute node*. + #. Do pre-deployment checks for hosts: -:: + :: - egrep -c '(vmx|svm)' /proc/cpuinfo + kolla-ansible -i ./multinode prechecks -If this command returns a value of **zero**, your compute node does not support -hardware acceleration and you **must** configure libvirt to use **QEMU** -instead of KVM. Create a file /etc/kolla/config/nova/nova-compute.conf and add -the content shown below. + #. Finally proceed to actual OpenStack deployment: -:: + :: - mkdir -p /etc/kolla/config/nova - cat << EOF > /etc/kolla/config/nova/nova-compute.conf - [libvirt] - virt_type = qemu - cpu_mode = none - EOF + kolla-ansible -i ./multinode deploy -For *all-in-one* deployments, the following commands can be run. These will -setup all of the containers on the localhost. These commands will be -wrapped in the kolla-script in the future. +* For development, run: -.. note:: Even for all-in-one installs it is possible to use the Docker - registry for deployment, although not strictly required. + #. Bootstrap servers with kolla deploy dependencies: -First, validate that the deployment targets are in a state where Kolla may -deploy to them. Provide the correct path to inventory file in the following -commands. + :: -:: + cd kolla-ansible/tools + ./kolla-ansible -i ./multinode bootstrap-servers - kolla-ansible prechecks -i /path/to/all-in-one + #. Do pre-deployment checks for hosts: -Deploy OpenStack. + :: -:: + ./kolla-ansible -i ./multinode prechecks - kolla-ansible deploy -i /path/to/all-in-one + #. Finally proceed to actual OpenStack deployment: -List the running containers. + :: -:: + ./kolla-ansible -i ./multinode deploy - docker ps -a +When this playbook finishes, OpenStack should be up, running and functional! +If error occurs during execution, refer to +`troubleshooting guide `_. -Generate the ``admin-openrc.sh`` file. The file will be created in -``/etc/kolla/`` directory. +Using OpenStack +~~~~~~~~~~~~~~~ + +OpenStack requires an openrc file where credentials for admin user etc are set. +To generate this file run :: kolla-ansible post-deploy + . /etc/kolla/admin-openrc.sh -Install the python-openstackclient as per followed installation. +Install basic OpenStack CLI clients: :: - pip install python-openstackclient + pip install python-openstackclient python-glanceclient python-neutronclient -To test your deployment, run the following commands to initialize the network -with a glance image and neutron networks. +Depending on how you installed Kolla-Ansible, there is script that will create +example networks, images, and so on. + +For pip install and CentOS host: :: - . /etc/kolla/admin-openrc.sh + . /usr/share/kolla-ansible/init-runonce - #centOS - /usr/share/kolla-ansible/init-runonce +For pip install and Ubuntu host: - #ubuntu - /usr/local/share/kolla-ansible/init-runonce +:: -.. note:: + . /usr/local/share/kolla-ansible/init-runonce - Different hardware results in variance with deployment times. +For git pulled source: + +:: -After successful deployment of OpenStack, the Horizon dashboard will be -available by entering IP address or hostname from ``kolla_external_fqdn``, or -``kolla_internal_fqdn``. If these variables were not set during deploy they -default to ``kolla_internal_vip_address``. + . kolla-ansible/tools/init-runonce -.. _Docker Hub Image Registry: https://hub.docker.com/u/kolla/ -.. _launchpad bug: https://bugs.launchpad.net/kolla/+filebug -.. _Building Container Images: https://docs.openstack.org/kolla/latest/admin/image-building.html