When working with an OpenStack installer, it is quite common to see changes happening in upstream projects break it. Options get deprecated every other day, new options show up, projects add dependencies… After all, this is one of the main reasons for RDO to have a continuous packaging pipeline coupled with CI jobs testing the latest commits.
However, in some cases we see some cross-project changes landing, and that takes quite a lot of coordination to happen, specially once we get passed the “it worked with DevStack!” point. As an example, I will discuss the switch from the MySQL-Python library to PyMySQL that happened during the Liberty cycle. We will follow the process from the initial decision until it got implemented in all projects (and DevStack), and then what it took us to get that change propagated into RDO and in the hands of our users.
In our previous article, we described how to create a simple OpenStack environment with a couple spare laptops.Now let’s assume you are a user in that cloud, and need to do something useful with it. What’s next?
Since part of my daily job is related to maintaining the Packstack codebase, I routinely run OpenStack installations every day… in a single VM, in my laptop, just to delete them a couple hours later. But sometimes I need to test some script or code over a live OpenStack installation, and I’d like to have a more stable environment to play with. Sure, there are public environments like TryStack, but I had a couple old laptops lying around, so why not play with them?
So the plan for today is to take these two laptops, install RDO on them, and have them be part of my home network, so that instances can connect to the Internet and get packages from the official repositories, and I can connect to them from my laptop using a floating IP in the same IP range as my home network.
As part of the onboarding process to the Packstack team, I had to understand how the Packstack internals work. There is no official documentation describing it, so when I learnt that some other colleagues would help us writing new plugins, I thought it would be a good idea to create something in written form. Using a series of blog posts by E.Nakai (available here) and some of my own reverse-engineering as a starting point, I have created this blog post.