CODEWITHSUNDEEP
databasemigrationopenstackkeystone
Alec Chepkin
Alec Chepkin

Reputation: 1

How to migrate OpenStack Keystone from Juno (2014.2.4) to Caracal (2024.1) with old database?

I'm currently working on upgrading OpenStack Keystone from Juno (2014.2.4) to Caracal (2024.1), but I’m encountering an issue with the database migrations.

The challenge is that there is a significant gap between these versions, and obviously, Caracal does not support upgrading directly from Juno. I need to find a way to bring the database schema up to the latest version.

Is there a recommended upgrade path for such an old version? Has anyone encountered a similar issue while upgrading across such a large version gap? What options could the community suggest to handle this situation?

I've considered manually upgrading through intermediate versions (Liberty, Ocata, etc.), but it seems complex, especially when dealing with custom Docker images and Python version incompatibilities.

Any advice or best practices would be appreciated!

Upvotes: 0

Views: 43

Answers (1)

eblock
eblock

Reputation: 551

This is not a definitive answer, but the comments are quite limited. You won't be able to upgrade directly to a newer release without stopping at each release in between. Since there have been so many releases between Juno and Caracal, upgrading the entire cloud 18 times (or 17 times since Bobcat was the first release to support skipping one) is quite a challenge. We had to go this path with a lot less releases in between, from Ocata to Ussuri, so only 5 releases.

We use our own cloud deployment mechanism (using the Salt framework) based on RPMs (meanwhile we migrated to Ubuntu and DEB packages). So what we did was to get all the required packages for all versions we needed to go through into our own (local) repository.

Then I built a controller VM in our existing cloud, based on Ocata. It was basically a single-control node cloud with all the services installed and running that our real cloud had running.

After importing the DB dump from our production cloud into the VM, I upgraded the cloud versions one by one in that VM, making sure the DB upgrades went through without any errors. Between each release I took a snapshot of the VM in case I encountered any errors so I could rollback to a working state, fix the errors and retried upgrading. Eventually, I was able to upgrade the DB until Ussuri and all the controller services still worked.

Then we reinstalled our control nodes with Ussuri, imported the DB dump from the VM and everything still worked. Of course, right before the reinstallation I had to go through the DB upgrade process again. This approach requires a DB freeze, which can be tricky depending on the clients. But this is how we would do it again.

Depending on your deployment method, e. g. kolla-ansible, you should check if and how you get access to the required container versions of the older OpenStack releases. I believe this was mentioned somewhere in the openstack-discuss mailing list, some sort of archive should exist.

Upvotes: 0

Related Questions