- What is OpenStack?
- Who maintains OpenStack in Debian? How to contribute?
- How to install OpenStack on Debian
- How Debian users should report bugs?
- What Ubuntu packages are maintained in Debian?
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
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://osbpo.debian.net/osbpo/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://osbpo.debian.net/osbpo stretch-queens-backports main deb http://osbpo.debian.net/osbpo stretch-queens-backports-nochange main deb http://osbpo.debian.net/osbpo stretch-rocky-backports main deb http://osbpo.debian.net/osbpo stretch-rocky-backports-nochange main deb http://osbpo.debian.net/osbpo buster-rocky-backports main deb http://osbpo.debian.net/osbpo buster-rocky-backports-nochange main deb http://osbpo.debian.net/osbpo buster-stein-backports main deb http://osbpo.debian.net/osbpo buster-stein-backports-nochange main deb http://osbpo.debian.net/osbpo buster-train-backports main deb http://osbpo.debian.net/osbpo buster-train-backports-nochange main deb http://osbpo.debian.net/osbpo buster-ussuri-backports main deb http://osbpo.debian.net/osbpo buster-ussuri-backports-nochange 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 version to just plain Buster which contains Rocky, and then proceed to the rest of the upgrade up to the latest version of OpenStack. The repository buster-rocky above contains some fixes not yet approved by the release team.
Note that what's below is notes if you use OCI, available from Debian, with the readme here:
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://osbpo.debian.net/osbpo buster-rocky-backports main deb http://osbpo.debian.net/osbpo buster-rocky-backports-nochange 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:
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
Upgrading 3 controllers from Stretch to Buster
While this isn't simple, it's possible to do a near-zero down time upgrade. Explanations on the method to do it are to follow here: http://thomas.goirand.fr/blog/?p=343
If you think, like me, that doing this by hand is too dangerous, you can use the script shipped with OCI: https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer/-/blob/debian/ussuri/bin/oci-cluster-upgrade-stretch-to-buster
Apart from gathering facts with OCI, which you can adapt to your deployment, the script should work for everyone with minimal adaptation.
You may find documentation on how to use and install OpenStack over here:
The official OpenStack documentation now including Debian specifics on a separated manual.
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?