1 de 9

Project overview and update

Dmitriy Rabotyagov�IRC: noonedeadpunk

05.06.2022

2 de 9

What does OpenStack-Ansible do?

Provides Ansible roles and playbooks for OpenStack deployment, configuration and day2 operations.

In LXC containers

Or bare metal

Can be deployed on:

Ubuntu

Debian

CentOS

Rocky Linux

OpenStack services can be installed

Inside virtualenvs

Or with distro packages

We can deploy

As you can see from the name, OpenStack-Ansible is an Official OpenStack Project, that provides Ansible roles and playbooks for deployment, configuration and day2 operations, such as upgrades. Our Ops repo also has roles that can help with monitoring and observability.

OpenStack-Ansible gives you some options about how to deploy OpenStack. Originally we started with deployment inside LXC containers, but since Stein we also support bare metal deployments with no containers.

OpenStack services can be built from source and installed with PIP inside virtualenvs, which is the preferred and most reliable way but they can also be installed with distro packages.

We support and test pretty wide selection of distros as well. You can use Ubuntu, Debian or CentOS Stream on your hosts. Or wait, I’ve almost forgotten. Since Yoga we also support Rocky Linux!

3 de 9

Why I should select OpenStack-Ansible?

It’s plain Ansible, without fuss

Very flexible

You can configure literally every setting in each service
Easy to scale out deployment - move RabbitMQ/MariaDB/anything to another host or manage that independently
You can use mix of supported OS (some running CentOS, some Ubuntu)

Keeping operator perspective as top priority

Supports deployments with limited connectivity or proxy servers

Reliable and reproducible deployments because of fixed SHAs for OpenStack projects ¹

¹When you do a “source” deployment in virtualenvs

Can deploy on just bare metal - no containers!

If you’re about to deploy OpenStack the first time or looking at how to improve or ease the deployment process, you will definitely ask why OpenStack-Ansible should be picked over other deployment tools.

And that is a really good question, which we will try to help you answer.

First of all, we’re trying to stay as close to Ansible philosophy as possible. 98% of our codebase is just simple Ansible roles and playbooks without any magic.

We also try to make deployments as flexible as possible by having overrides for most of the config files or deployment options you can think of. You can control what version of each service will be installed and use your own fork of it if needed.

Because we have a way to manage ansible inventory and a pretty wide selection of pre-defined groups and variables, you can scale-out service components (like nova-api and nova-conductor) on different hosts or have different rabbitmq/galera clusters per OpenStack service.

Also, you can also have a mix of operating systems in the deployment, like having some hypervisor nodes running CentOS and some Ubuntu.

So there’s no easy answer on what deployment tool to use, but I hope I’ve provided some information to help you choose.

4 de 9

Project background

Founded during the Kilo release of OpenStack (April 2015)
We have 30 contributors, 570 commits and 37 bugs closed during Yoga release.

Latest user survey adoption numbers:

23% of clouds running OSA in production�4 % are on test phase�8% are considering it for usage�
At same time 47% of respondents said they’re using Ansible for managing their deployments.

5 de 9

New features & enhancements for Yoga

LSYNCD on repo containers is replaced with GlusterFS by default

Operators can opt-out from GlusterFS installation and use any shared FS they already manage (like CephFS or NFS).

SSH auth for keystone and computes is now handled with SSH certificates by ssh_keypairs role.

No longer necessary to synchronize SSH keys across all computes when new one is added!

Octavia is now leveraging PKI role for Amphora certificates

Be careful during OpenStack upgrade.

Support for Rocky Linux is added

Huge thanks to Neil Hanlon for making that happen

Support for CentOS 9 Stream is added

You should upgrade to it during Yoga. CentOS 8 Stream support will be dropped in Zed.

Experimental support for Ubuntu 22.04 has been added

Just believe us - it’s really experimental

Now let’s talk about project achievements during Yoga cycle.

First of all, we finally removed lsyncd from repo containers. The repo container is used for building Python Wheels, to reduce outgoing traffic and spend less time building packages for installation onto all hosts.

When wheels were built, we were syncing between several repo containers using lsyncd. However, there were several issues with that. lsyncd was barely maintained lately. Also, one repo container acted as an origin, which made OS upgrades tricky, as well giving problems supporting multi-OS deployments, as wheels are OS-dependent.

Now we've replaced lsyncd with a shared file system. By default we deploy GlusterFS. However, if you already have a filesystem, like NFS or CephFS, just define a variable to use your mount and it will be used inside the repo containers. The systemd_mount role is used for managing mounts.

Next, we have replaced SSH key-based authorization on keystone and nova computes with ssh certificate-based auth. Ssh_keypairs role is in charge of this process now. As a result, you don’t need to run nova playbook across all computes to sync keys needed for live migration when adding another node to the cluster.

Octavia was the last role that was not using PKI role for certificates management and we finally managed to fix that. But you should be careful during upgrades. We have an upgrade playbook to migrate existing certificates for general cases but if you have overrides or some special scenario for Octavia Amphora certificates - better to double-check.

We also have added support for several new distributions. Neil has brought in Rocky Linux and helps with its maintenance and support.

Also, we’ve just merged CentOS 9 Stream support. As in Zed OpenStack drops Python 3.6, it’s highly likely that Yoga will be an upgrade release for CentOS, because CentOS 8 Stream does not have python 3.8 bindings for libvirt.

And finally Ubuntu 22.04 experimental support added. At the moment some repositories (like MariaDB of RabbitMQ ones) still don’t have Jammy versions. So its support is really experimental. We expect things to stabilize in Zed.

6 de 9

Why Yoga is still not released for OSA?

OpenStack-Ansible is trailing behind official releases to be able to adopt and properly test OpenStack deployments after official release.

But you can try out Beta release tagged as 25.0.0.0b1 today!

Final release 25.0.0 will be available before June 23rd 2022

7 de 9

Possible features & enhancements for Zed

Ceph-Ansible is being deprecated by its upstream maintainers, so we have to deprecate it and remove it from OSA as well

Future of how we are going to deploy Ceph is vague at the moment.

Internal SSL

Encrypting connection between HaProxy and uWSGI backends

Keystone System Role assignments
Experimental ansible role for Skyline dashboard

As we covered things for Yoga, it’s now time to talk About the future.

Zed. What’s going to happen there?

First of all bad news about Ceph-Ansible. As you might know, the project has been deprecated by maintainers in favor of CephAdm. There is no other choice but to deprecate it as well in OSA.

We haven’t agreed yet on how we’re going to proceed with Ceph deployments in the future, as cephadm doesn’t really fit us. We don’t have a decision on this topic yet, so feel free to chime in with suggestions!

Next, we’re looking into implementing encryption between our Load Balancer and the Service APIs (uwsgi). We already have proof of concept that looks very promising. Who knows - maybe we will land it even before the final release!

Keystone System Role Assignments. As you might know, this is huge OpenStack-wide work that has been started during Victoria release cycle that aims to get better Role based access control in keystone and policies in projects. Of course, this has to be handled properly by deployment projects.

And also we’re going to provide experimental Skyline dashboard deployment. Skyline is an alternative to Horizon but it has a quite big feature gap. It’s under active development at the moment so we have a big expectations here.

8 de 9

We need your help!

Requests:

Maintainers for CentOS are needed
More contributors and reviewers!

As with many OpenSource projects, we have more ambitions than time to work on them. So we are not unique and need some help maintaining things.

After the CentOS Stream announcements, a lot of deployments moved to different OS, which resulted in a lack of contributors to keep that CentOS support alive.

We believe that supporting Rocky Linux support should bring some new blood, so if you’re interested - let us know!

We always appreciate contributions and trying to bring in more use-cases and capabilities to the code. If you have some new scenario in mind - please don’t be afraid to share that with us so we can improve OpenStack-Ansible for everyone.

And of course, we encourage everybody to contribute at least with patch reviews. Code review is vital as it shows that we’re heading into the right or wrong direction. So don’t hesitate to spend several minutes of your time on reviews, they do matter.

9 de 9

THANKS.

OFTC IRC: #openstack-ansible

openstack

OpenInfraFoundation

@OpenStack