> through puppet, manually or ansible or what-ever) it's complicated or even
impossible to revert.
Well, that's pretty much the reason why in OpenStack-Ansible (and actually Kolla) we don't go this route by default, but installing most of the services as Python packages inside virtual environments.
And repositories for supporting tools (like mariadb, rabbitmq, etc) are versioned. So if you have 3 control planes, 1 on Rocky Linux, 1 on Debian and 1 on Ubuntu - all of them will have same versions of mariadb/rabbitmq and OpenStack services, and they can work together.
However, your biggest issue with revert is change of database and/or RPC schema, which makes revert way more touch.
And I don't think there's anything which can solve the database schema issue during rollback without losing data which was created after upgrade.
Le 07/03/2025 à 10:03:05+0100, Francesco Di Nucci a écrit
Hi,
>
> My two cents - "ease" of upgrade is more related to planning the OpenStack
> components setup than to the deployment method
>
> An alternative for bare metal is use a couple of servers as KVM hypervisors
> to host management VMs (Keystone, Cinder etc) and install Nova compute on
> the other ones, automating with Foreman+Puppet
Yeah....we use intensively puppet.
But that's not solve the «problem» with openstack. Long time ago (few
years) when upgrading openstack they are lot of thing to do (change of
config etc.) and the main issue is when you deploy with “apt install”
(through puppet, manually or ansible or what-ever) it's complicated or even
impossible to revert.
For example when Debian upgrade xxxx from version a.b.c to a+1.b1.c1 and
broke something in openstack we are in deep s*t.
Regards
--
Albert SHIH 🦫 🐸
Observatoire de Paris
France
Heure locale/Local time:
mar. 11 mars 2025 10:23:30 CET