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. On Tue, 11 Mar 2025, 10:28 Albert Shih, <Albert.Shih@obspm.fr> wrote:
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