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 ?