quickstart.rst

Deployment of Kolla on Bare Metal or Virtual Machine

Evaluation and Developer Environments

Two virtualized development environment options are available for Kolla. These options permit the development of Kolla without disrupting the host operating system.

If developing Kolla on an OpenStack cloud environment that supports Heat, follow the :doc:`Heat developer environment guide <heat-dev-env>`.

If developing Kolla on a system that provides VirtualBox or Libvirt in addition to Vagrant, use the Vagrant virtual environment documented in :doc:`Vagrant developer environment guide <vagrant-dev-env>`.

Currently the Heat development environment is entirely non-functional. The Kolla core reviewers have debated removing it from the repository but have resisted to provide an opportunity for contributors to make Heat usable for Kolla development. THe Kolla core reviewers believe Heat would offer a great way to develop Kolla in addition to Vagrant, bare metal, or a manually setup virtual machine.

For more information refer to _bug 1562334.

If evaluating Kolla, the community strongly recommends using bare metal or a virtual machine during the evaluation period. Follow the instructions in this document to get started with deploying OpenStack on bare metal or a virtual machine with Kolla.

Host machine requirements

The recommended deployment target requirements:

• 2 (or more) network interfaces.
• At least 8gb main memory
• At least 40gb disk space.

Note

Some commands below may require root permissions (e.g. pip, apt-get).

Installing Dependencies

Kolla is tested on CentOS, Oracle Linux, RHEL and Ubuntu as both container OS platforms and bare metal deployment targets.

Fedora: Kolla will not run on Fedora 22 and later as a bare metal deployment target. These distributions compress kernel modules with the .xz compressed format. The guestfs system in the CentOS family of containers cannot read these images because a dependent package supermin in CentOS needs to be updated to add .xz compressed format support.

Ubuntu: For Ubuntu based systems where Docker is used it is recommended to use the latest available LTS kernel. The latest LTS kernel available is the wily kernel (version 4.2). While all kernels should work for Docker, some older kernels may have issues with some of the different Docker backends such as AUFS and OverlayFS. In order to update kernel in Ubuntu 14.04 LTS to 4.2, run:

apt-get install linux-image-generic-lts-wily

Note

Install is very sensitive about version of components. Please review carefully because default Operating System repos are likely out of date.

Component	Min Version	Max Version	Comment
Ansible	1.9.4	< 2.0.0	On deployment host
Docker	1.10.0	none	On target nodes
Docker Python	1.6.0	none	On target nodes
Python Jinja2	2.6.0	none	On deployment host

Make sure the "pip" package manager is installed before proceeding:

# CentOS 7
yum install epel-release
yum install python-pip

# Ubuntu 14.04 LTS
apt-get install python-pip

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:

curl -sSL https://get.docker.io | bash

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. 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

# Run these commands to reload the daemon
systemctl daemon-reload
systemctl restart docker

For Ubuntu 14.04 which uses upstart instead of systemd, run the following:

mount --make-shared /run

On the target hosts you also need an updated version of the Docker python libraries. CentOS currently ships with an older version. Using pip it is easy to install a newer version:

pip install -U docker-py

On the system where the OpenStack CLI/Python code is run, the Kolla community recommends installing the OpenStack python clients if they are not installed. This could be a completely different machine then the deployment host or deployment targets. Before installing the OpenStack python client, the following requirements are needed to build the client code:

# Ubuntu
apt-get install -y python-dev libffi-dev libssl-dev gcc git

# CentOS 7
yum install -y python-devel libffi-devel openssl-devel gcc git

To install these clients use:

pip install -U python-openstackclient

To clone the Kolla repo:

git clone https://git.openstack.org/openstack/kolla

To install Kolla tools and Python dependencies use:

pip install kolla/

Copy Kolla configuration to /etc:

cd kolla
cp -r etc/kolla /etc/

Optionally, you can install tox and generate the build configuration using following steps.

pip install tox
tox -e genconfig

The location of the generated configuration file is etc/kolla/kolla-build.conf, You can also copy it to /etc/kolla. The default location is one of /etc/kolla/kolla-build.conf or etc/kolla/kolla-build.conf.

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 -y install ntp
systemctl enable ntpd.service
systemctl start ntpd.service