Is there a way to upgrade openstack older versions like ussuri , victoria, by migrating just the nova, neutron dbs, schema to the latest version by skipping one level at once and then install the latest venvs against the latest migrated galera dbs. On the compute nodes, if we preserve just the var lib nova instances and on top of it reinstall the compute and neutron agents, will it work ? I am asking becos, I don't know what r the dependencies among the major nova versions. Are the db schema and data, the only diffs from one version to another, or is there any thing else ?
Such upgrades are not supported and you will most definitely run into issues and errors when attempting to upgrade various services. There is a way to do it only if you know exactly what you are doing and are ready to figure it out on your own. And it will involve some hackery and workarounds for sure. Main things to look out for: * if database migrations are still present and actually executed. As services were wiping out old migrations around Victoria/Wallaby, assuming everyone has the latest db schema anyway. * RPC versions compatibility * Python/OS/libvirt versions compatibility ср, 29 янв. 2025 г. в 14:11, engineer2024 <engineerlinux2024@gmail.com>:
Is there a way to upgrade openstack older versions like ussuri , victoria, by migrating just the nova, neutron dbs, schema to the latest version by skipping one level at once and then install the latest venvs against the latest migrated galera dbs. On the compute nodes, if we preserve just the var lib nova instances and on top of it reinstall the compute and neutron agents, will it work ?
I am asking becos, I don't know what r the dependencies among the major nova versions. Are the db schema and data, the only diffs from one version to another, or is there any thing else ?
On 2025-01-29 14:20:46 +0100 (+0100), Dmitriy Rabotyagov wrote:
Such upgrades are not supported and you will most definitely run into issues and errors when attempting to upgrade various services. [...]
Though once you get it upgraded to Yoga, unofficially it's probably safe to skip over Zed and upgrade straight from Yoga to 2023.1/Antelope. After that, it's officially safe to skip over 2023.2/Bobcat directly to 2024.1/Caracal (and then skip 2024.2/Dalmatian to run 2025.1/Epoxy once it exists in a couple more months). -- Jeremy Stanley
Yes, totally, thanks for correcting me! I was talking only in aspect of older releases. In OpenStack-Ansible we indeed had testing of direct upgrade from Yoga to the first official SLURP release - 2023.1 And then you can upgrade between SLURPs safely. On Wed, 29 Jan 2025, 14:27 Jeremy Stanley, <fungi@yuggoth.org> wrote:
On 2025-01-29 14:20:46 +0100 (+0100), Dmitriy Rabotyagov wrote:
Such upgrades are not supported and you will most definitely run into issues and errors when attempting to upgrade various services. [...]
Though once you get it upgraded to Yoga, unofficially it's probably safe to skip over Zed and upgrade straight from Yoga to 2023.1/Antelope. After that, it's officially safe to skip over 2023.2/Bobcat directly to 2024.1/Caracal (and then skip 2024.2/Dalmatian to run 2025.1/Epoxy once it exists in a couple more months). -- Jeremy Stanley
---- On Wed, 29 Jan 2025 05:48:03 -0800 Dmitriy Rabotyagov wrote ---
Yes, totally, thanks for correcting me! I was talking only in aspect of older releases. In OpenStack-Ansible we indeed had testing of direct upgrade from Yoga to the first official SLURP release - 2023.1 And then you can upgrade between SLURPs safely.
A few of the services started testing the skip level upgrade since Yoga (yoga -> antelope). We had a grenade job testing it, so at least (nova, placement, cinder, glance, neutron, swift, Keystone, and horizon) services were working fine. I am not sure if any other services tested that as a voting job. -gmann
On Wed, 29 Jan 2025, 14:27 Jeremy Stanley, fungi@yuggoth.org> wrote: On 2025-01-29 14:20:46 +0100 (+0100), Dmitriy Rabotyagov wrote:
Such upgrades are not supported and you will most definitely run into issues and errors when attempting to upgrade various services. [...]
Though once you get it upgraded to Yoga, unofficially it's probably safe to skip over Zed and upgrade straight from Yoga to 2023.1/Antelope. After that, it's officially safe to skip over 2023.2/Bobcat directly to 2024.1/Caracal (and then skip 2024.2/Dalmatian to run 2025.1/Epoxy once it exists in a couple more months). -- Jeremy Stanley
I'm noting that this is not officially supported advice; just stuff I've seen done in real life and talked about at summits. Backup everything if you try it and if it breaks, you may just have to revert. Doing the upgrade in one shot: a really bad idea. Doing a bunch of quick, successive upgrades during a single upgrade-downtime? Maybe OK? I would still assume, as others have mentioned on this thread, there's a potential for a headache or two but this may limit them. Consider a process similar to the following: - Prepare a virtualenv for the entire matrix of [all openstack services to upgrade] x [all openstack versions you need to upgrade through] - Shut down openstack services - Load up virtualenv for service N, release N+1, run the upgrade scripts it provides - Load up virtualenv for next service, same release - Repeat until all services are upgraded to release "N+1", then repeat for "N+2". When you get the upgrade commands run, then actually upgrade and restart your services. I hope you get the idea. I'm not perfectly enumerating it because it's not a prescribed or supported idea, just a way to mitigate your risks if you choose to do the upgrade at once. - Jay Faulkner On 1/29/25 5:10 AM, engineer2024 wrote:
Is there a way to upgrade openstack older versions like ussuri , victoria, by migrating just the nova, neutron dbs, schema to the latest version by skipping one level at once and then install the latest venvs against the latest migrated galera dbs. On the compute nodes, if we preserve just the var lib nova instances and on top of it reinstall the compute and neutron agents, will it work ?
I am asking becos, I don't know what r the dependencies among the major nova versions. Are the db schema and data, the only diffs from one version to another, or is there any thing else ?
participants (5)
-
Dmitriy Rabotyagov
-
engineer2024
-
Ghanshyam Mann
-
Jay Faulkner
-
Jeremy Stanley