Successfully resetting the root password of a CentOS 7 VM in OpenStack

Even in a cloud world, sometimes you need to find a way to get inside your VM when SSH doesn’t work. Maybe your Ansible script broke the SSH configuration and you need to debug it, or you lost the key you used when creating the VM, or <insert random reason here>.

The good news is that OpenStack environments give you a connection to the VM console. However, CentOS 7 (and RHEL 7) images are a bit tricky when you want to boot in single user mode, as they request the root password, which we don’t have. There is a well documented procedure to boot using rd.break, but there are some little quirks to adapt it for OpenStack images. But fear not, I have summarized them in this post.

Advertisement

Anatomy of an OpenStack distribution

Last week I went to an internal developer event of a Red Hat customer, and presented RDO, our workflow and tools for continuous packaging with my colleague Alfredo Moralejo. This presentation came from an proposal dmsimard and I had for the Barcelona OpenStack Summit, but did not get accepted, so hey, at least it got somewhere.

The audience was quite technical, and they seemed to be happy with the content, since the Q&A session went on for about 25 minutes  :).

Interested in the seeing the slides? You can check them online.

Getting cross-project changes in OpenStack to our user’s hands

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.

You have a user in a shiny, new OpenStack cloud. Now what?

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?

Creating a home OpenStack lab with RDO and a couple spare laptops

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.

Writing Packstack plugins

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.