Translation(s): English - Français


What is OpenStack?

OpenStack is by far the largest free software IaaS (infrastructure as a service) cloud project. It receives collaboration of developers and cloud computing technologists producing the ubiquitous Free Software cloud computing platform for public and private clouds. The project aims to deliver solutions for all types of clouds by being simple to implement, massively scalable, and feature rich. The technology consists of a series of interrelated projects delivering various components for a cloud infrastructure solution.

Who maintains OpenStack in Debian? How to contribute?

The OpenStack Debian GNU/Linux packages are maintained by a team managed on salsa.debian.org available daily, either through the OpenStack packaging mailing list or via IRC on #debian-openstack on the OFTC network.

Also, the team now maintains a /OpenStack/todo on the packaging work.

How to install OpenStack on Debian

Using Debian unstable/testing

We very much encourage everyone to use Debian testing/unstable to run OpenStack. Bug reports welcome! :)

Using a pure Debian Stable or adding Debian backports repositories

Debian users are given the choice to just use whatever version of OpenStack is in Debian, during the lifetime of Stable. OpenStack packages are currently not supported when your stable Debian becomes LTS (volunteers to do the work are welcome). So if you choose Stable, you roughly need to either upgrade through each backport repositories or make a new deployment (see below).

If you decide to use the debian.net backport repositories, then currently, the OpenStack team only guarantee security support for them for the first 6 months of the release, until we push a new release to Unstable.

Upgrading OpenStack in Debian

Generalities

Upgrades to fix CVEs which I publish in Debian stable have always been painless (I cross fingers that it continues this way).

As it's not possible to skip an upstream release when upgrading, if you wish to upgrade a deployment from one Debian stable release to another, then you must use the team's unofficial backport repositories.

You will need archive key installed. For example:

curl http://stretch-queens.debian.net/debian/dists/pubkey.gpg | sudo apt-key add -

curl http://stretch-rocky.debian.net/debian/dists/pubkey.gpg | sudo apt-key add -

curl http://buster-stein.debian.net/debian/dists/pubkey.gpg | sudo apt-key add -

curl http://buster-train.debian.net/debian/dists/pubkey.gpg | sudo apt-key add -

These repositories *always* built using the exact same Git tree than in Debian unstable, and are backports of each OpenStack releases to the latest Debian Stable. Here's a few of the last of these repositories:

deb http://stretch-queens.debian.net/debian stretch-queens-backports main
deb http://stretch-queens.debian.net/debian stretch-queens-backports-nochanges main

deb http://stretch-rocky.debian.net/debian stretch-rocky-backports main
deb http://stretch-rocky.debian.net/debian stretch-rocky-backports-nochanges main

deb http://buster-stein.debian.net/debian buster-stein-backports main
deb http://buster-stein.debian.net/debian buster-stein-backports-nochanges main

deb http://buster-train.debian.net/debian buster-train-backports main
deb http://buster-train.debian.net/debian buster-train-backports-nochanges main

If you think upgrading 5 OpenStack release in your cluster is too much work for just upgrading a Debian OpenStack cloud running stable, then what's suggested is to *not* do upgrade, and instead, install a new deployment and migrate your workload to a new deployment on the next Debian release.

Also note that it's suggested to upgrade from the stretch-rocky.debian.net version to just plain Buster which contains Rocky, and then proceed to the rest of the upgrade up to the latest version of OpenStack.

Note that what's below is notes if you use OCI, available from Debian, with the readme here:

https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer

Upgrading from stretch-rocky to buster-rocky

Buster point release packages

There's still a few packages that need to be approved by the release team to make the upgrade smooth. In the mean while, we are strongly advising to use this repository on top of Buster to have a few updates which aren't yet in the latest Buster point release:

deb http://stretch-rocky.debian.net/debian buster-rocky-proposed-updates main
deb-src http://stretch-rocky.debian.net/debian buster-rocky-proposed-updates main

for the details of the update, see the release team bugs: #941901, #942102, #944099, #944594. Note that python3-oslo.messaging has already been approved and will be in Buster 10.2.

Upgrading a compute node

Before upgrading any other workload, best is to upgrade compute nodes first. To do so, disable the compute node with:

openstack compute service set --disable hostname-compute-1.example.com nova-compute

Then live migrate all VMs in them first, with commands like this one:

openstack server migrate --live hostname-compute-3.infomaniak.ch --block-migration 8dac2f33-d4fd-4c11-b814-5f6959fe9aac

Then you can safely do the upgrade. First, turn off puppet:

systemctl stop puppet.service

If you were using upstream's Ceph repository, remove them, and remove the components:

apt-get remove python3-rgw python3-rbd python3-rados python3-cephfs librgw2 librbd1 librados2 libcephfs2

then switch to the buster repository, eventually add the buster-rocky repository, and perform a full dist-upgrade. Reboot the compute node, reapply your favorite compute management tool (maybe: puppet agent -t).

During this process, just press enter for any debconf prompt from OpenStack so it doesn't touch any of your configuration. Best is probably to reconfigure debconf to use the non-interactive mode with:

dpkg-reconfigure debconf

then select non-interactive there.

During the upgrade, you may be asked to overwrite some configuration files. It's best to say yes for: - /etc/ssh/ssh_config - the 3 libvirt files: /etc/default/libvirtd /etc/libvirt/libvirtd.conf and /etc/libvirt/qemu.conf - /etc/sysctl.conf

Don't do that for (ie: just press enter): - /etc/haproxy/haproxy.cfg - /etc/chrony/chrony.conf

For those it doesn't matter much, because they will be overwritten by the next puppet run anyway, but then, no need to get the default package version either...

Note that, for live migration to continue to work, you need to get security_driver = "apparmor" in /etc/libvirt/qemu.conf, and install apparmor. The OCI puppet scripts will do that for you.

Reboot the compute node.

Apply puppet with:

puppet agent -t

Re-enable the compute node:

openstack compute service set --enable hostname-compute-1.example.com nova-compute

It's also best to remove old linux kernels:

apt-get purge linux-image-4.19.0-0.bpo.5-amd64 linux-image-4.9.0-9-amd64

Documentation

You may find documentation on how to use and install OpenStack over here:

How Debian users should report bugs?

Bugs shall be reported against the Debian packages the same way as the for other packages in Debian. If you don't know how to do it, you can read this page on the official Debian site.

What Ubuntu packages are maintained in Debian?


CategoryVirtualization | CategorySoftware | CategorySystemAdministration