 Hi everybody. I am happy to present recent project updates that have happened in OpenStack Ansible during the last release. Along with that, I will also tell you what the project is and what goals we have. As you can see from the name, OpenStack Ansible is an official OpenStack project that provides Ansible roles and playbooks for deployment, configuration and date to 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 time, we also support bare metal deployments with no containers. OpenStack services can build from source and installed with PIP inside Twitterlamps, which is the preferred and most reliable way, but they also can be installed with distro packages. We support and test pretty wide selection of distros as well. You can use Ubuntu, Debian or CentaurStream on your hosts. Oh wait, I've almost forgotten. Since Yoga we also support Rocky Linux. If you are 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 are trying to stay as close to Ansible philosophy as possible. 98% of our code base 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 sync off. You can control what version of each service will be installed and use your own folk if it's needed. Because we have a way to manage Ansible inventory and a pretty wide selection of predefined groups and variables, you can scale out service components like Nova API and Nova Conductor on different hosts or have different Rebit and Kuglero clusters per OpenStack service. Also, you can have a mix of operating systems in the deployment like having some hypervisor nodes running CentaurStream and some Ubuntu. So there is no easy answer on what deployment tool to use but I hope I've provided some information to help you choose. Let's talk about the project history and contribution has. OpenStack Ansible was first released in Kiva and has evolved dramatically since then. It was founded by REC Space but became widely adopted and used by other companies. During your release, we had more than 30 contributors with 570 commits made. As you can see on the graph, contributions are split between several companies so we managed to keep balance of interest. According to 2021 users survey, about 30% of users either run OpenStack Ansible in production or try it for testing. And about half of all OpenStack users say they're comfortable with Ansible and use it for managing the infrastructure so we even have space to grow. Now let's talk about project achievements during the Yoga Cycle. First of all, we finally removed LCND 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 the all hosts. When wheels were built, we were thinking between several repo containers using LCND. However, there were several issues with that. LCND was barely maintained lately. Also, one repo container acted as an origin which made OS upgrade streaky as well, giving problems supporting multi OS deployments as we are always dependent. Now we've replaced LCND with a shard file system. By default, we deploy Gloucester FS. However, if you already have a file system like NFS or ZFFS, just define a variable to use your mount and it will be used inside the repo containers. The system demount role is used for managing mounts. Next, we have replaced SSR key based authorization on Keystone and Nova Computes with SSR certificate based OS. SSR key pairs role is in charge of this process now. As a result, you don't need to run Nova Playbooks across all computers to send keys needed for live migration when adding another node to the cluster. Octavia was the last role that wasn't using PKI for certificates management and we finally managed to fix that. But you should be careful during upgrades. You have an upgrade Playbook to migrate existing certificates for general cases, but if you have overrides or some special scenario for Octavia unforever certificates, better to double check. We also have added support for several new distributions. Nail has brought in Rocky Linux and helps with its maintenance and support. Also, we've just merged CentOS 9 stream support. As in that OpenStack drops Python 3.6, it's highly likely that Yoga will be an upgrade release for CentOS because CentOS 8 stream doesn't have Python 3.8 bindings for Livered. And finally Ubuntu 22.04 experimental support added. At the moment, some repositories like MariaDB or RabbitMQ ones still don't have Yammer versions. So its support is really experimental. We expect things to stabilize in that. So why are we talking about Yoga, while OpenStack and SableStick haven't released it? Shouldn't also as an official project released with the whole OpenStack? Well, no. Also, it's trailing release project, which means that it releases several months after the official OpenStack release. It's done this way, so we could properly test the Yoga deployment after the main services make their release. Because in practice, some breaking changes can land in projects close to the release that would break deployment. So to be safe and provide good quality real estate later. And talking about testing, our better release of Yoga should be already ready and you can try it out. The first supported release of Yoga for OpenStack and Sable will be available on June 23. As we've covered since for Yoga, it's now time to talk about the future. That was going to happen there. First of all, bad news about self-ensible. As you might know, the project has been deprecated by maintainers in favor of self-harm. There is no other choice but to deprecate it as well in also. We haven't agreed yet on how we are going to proceed with self-deployment in the future, as the plan 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. You only 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 wired work that has been started during Victoria release cycle that aims to get better role-based access control in Keystone and policies and projects. Of course, this has to be handled properly by deployment projects. And also, we are 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, so we have a big expectations here. As with many open source projects, we have more ambitions and time to work on them. So we are not unique and need some help maintaining things. After that sent us through announcements, a lot of deployments moved to different operating systems, which resulted in the lack of contributors to keep that center support alive. We believe that supporting Roque Linux should bring some new blood, so if you're interested, let us know. We always appreciate contributors and trying to bring in more use cases and capabilities to the code. If you have some news 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 are heading into the right or wrong direction. So don't hesitate to spend several minutes of your time on reviews. They do matter. In case of any questions or suggestions, please reach us via IRC on the OVDC network. Thanks for your time.