openstack/kayobe
Code Issues Proposed changes
kayobe/doc/source/development/automated.rst
Mark Goddard 6266312fa1 Test upgrades in CI 
There is currently no coverage of upgrades in CI, which leaves us open
to regression in this infrequently tested but crucial area. This change
adds the required scripts and Zuul configuration.

A control plane is first deployed using the Kayobe stable/pike branch
and associated default configuration. The control plane is tested by
deploying then deleting a server instance. An upgrade to Queens is
performed, using the Kayobe master branch, or code in review if
applicable. The upgraded control plane is tested by deploying then
deleting a second server instance.

A workaround was required to restart the nova_compute service after the
upgrade, since the SIGHUP sent to it by Kolla Ansible during upgrade
appeared to be putting it into a degraded state.

A future improvement to this test could be to leave a server instance
running during the upgrade.

Change-Id: I0e595524e39d1131fe3ec6aaf2aeec3ff3d6a536
Story: 2003472
Task: 24732
2018-11-05 12:02:31 +00:00

5.4 KiB
Raw Blame History

Automated Setup

This section provides information on the development tools provided by kayobe to automate the deployment of various development environments.

For a manual procedure, see development-manual.

Overview

The kayobe development environment automation tooling is built using simple shell scripts. Some minimal configuration can be applied by setting the environment variables in dev/config.sh. Control plane configuration is typically provided via the kayobe-config-dev repository, although it is also possible to use your own kayobe configuration. This allows us to build a development environment that is as close to production as possible.

Environments

The following development environments are supported:

  • Overcloud (single OpenStack controller)
  • Seed hypervisor
  • Seed VM

The seed VM environment may be used in an environment already deployed as a seed hypervisor.

Overcloud

Preparation

Clone the kayobe repository:

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

Change the current directory to the kayobe repository:

cd kayobe

Clone the kayobe-config-dev repository to config/src/kayobe-config:

mkdir -p config/src
git clone https://git.openstack.org/openstack/kayobe-config-dev.git config/src/kayobe-config

Inspect the kayobe configuration and make any changes necessary for your environment.

If using Vagrant, follow the steps in development-vagrant to prepare your environment for use with Vagrant and bring up a Vagrant VM.

If not using Vagrant, the default development configuration expects the presence of a bridge interface on the OpenStack controller host to carry control plane traffic. The bridge should be named breth1 with a single port eth1, and an IP address of 192.168.33.3/24. This can be modified by editing config/src/kayobe-config/etc/kayobe/inventory/group_vars/controllers/network-interfaces. Alternatively, this can be added using the following commands:

sudo ip l add breth1 type bridge
sudo ip l set breth1 up
sudo ip a add 192.168.33.3/24 dev breth1
sudo ip l add eth1 type dummy
sudo ip l set eth1 up
sudo ip l set eth1 master breth1

Usage

If using Vagrant, SSH into the Vagrant VM and change to the shared directory:

vagrant ssh
cd /vagrant

If not using Vagrant, run the dev/install.sh script to install kayobe and its dependencies in a virtual environment:

./dev/install.sh

Run the dev/overcloud-deploy.sh script to deploy the OpenStack control plane:

./dev/overcloud-deploy.sh

Upon successful completion of this script, the control plane will be active.

The control plane can be tested by running the dev/overcloud-test.sh script. This will run the init-runonce setup script provided by Kolla Ansible that registers images, networks, flavors etc. It will then deploy a virtual server instance, and delete it once it becomes active:

./dev/overcloud-test.sh

It is possible to test an upgrade by running the dev/overcloud-upgrade.sh script:

./dev/overcloud-upgrade.sh

Seed Hypervisor

The seed hypervisor development environment is supported for CentOS 7. The system must be either bare metal, or a VM on a system with nested virtualisation enabled.

Preparation

The following commands should be executed on the seed hypervisor.

Clone the kayobe repository:

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

Change the current directory to the kayobe repository:

cd kayobe

Clone the add-seed-and-hv branch of the kayobe-config-dev repository to config/src/kayobe-config:

mkdir -p config/src
git clone https://github.com/markgoddard/dev-kayobe-config -b add-seed-and-hv config/src/kayobe-config

Inspect the kayobe configuration and make any changes necessary for your environment.

Usage

Run the dev/install.sh script to install kayobe and its dependencies in a virtual environment:

./dev/install.sh

Run the dev/seed-hypervisor-deploy.sh script to deploy the seed hypervisor:

./dev/seed-hypervisor-deploy.sh

Upon successful completion of this script, the seed hypervisor will be active.

Seed VM

The seed VM should be deployed on a system configured as a libvirt/KVM hypervisor, using the kayobe seed hypervisor support or otherwise.

Preparation

The following commands should be executed on the seed hypervisor.

Change the current directory to the kayobe repository:

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

Change to the kayobe directory:

cd kayobe

Clone the add-seed-and-hv branch of the kayobe-config-dev repository to config/src/kayobe-config:

mkdir -p config/src
git clone https://github.com/markgoddard/dev-kayobe-config -b add-seed-and-hv config/src/kayobe-config

Inspect the kayobe configuration and make any changes necessary for your environment.

Usage

Run the dev/install.sh script to install kayobe and its dependencies in a virtual environment:

./dev/install.sh

Run the dev/seed-deploy.sh script to deploy the seed VM:

./dev/seed-deploy.sh

Upon successful completion of this script, the seed VM will be active. The seed VM may be accessed via SSH as the stack user:

ssh stack@192.168.33.5