You can set `rabbitmq_install_method: distro` in user_variables and rabbitmq will get installed from distro-provided repositories rather then external ones: https://opendev.org/openstack/openstack-ansible-rabbitmq_server/src/branch/m... But yes, default behaviour is to use external repos.

You're slightly wrong about reasons behind why this behaviour is default though. It's not about having "latest" versions, it's about having consistent/same versions across all distributions. First of all, then related bugs and security vulnerabilities are the same for all distros, so it's kinda easier to keep track on that. But then most important part is cross-distro installations. So let's assume an individual is running Ubuntu (or CentOS, doesn't matter), and they want to migrate to Debian. Having different rabbitmq versions installed by these distributions will totally be a blocker for such resilient migration. At the same time, when exactly the same versions of rabbit/erlang/galera are installed - they can just re-setup control planes one by one to another distro without any pain and the cluster will remain functional.

чт, 1 июн. 2023 г. в 13:00, Thomas Goirand zigo@debian.org:

On 5/28/23 02:27, Dmitriy Rabotyagov wrote:

...

That is just ridiculous... We have just switched from cloudsmith because it's rotating packages too aggressively...

IMO, what's ridiculous, is to insist using upstream broken-by-design repositories for each-and-every-component (this event illustrate it well...), just because you want the latest upstream release of everything for no valid reason (as if what was released 2 weeks ago is not relevant anymore...).

On the specific case of RabbitMQ, this means using the upstream repo version of erlang, meaning that everything else that is packaged in the distro that uses erlang is broken.

If there was any valid reason to do a backport of a component in stable-backports (for Debian), or even if it was a personal preference of the OSA team, I would have happily done the work. Though never ever, the OSA / Kolla team got in touch with me for this kind of things.

Another issue is that, if you want to do an off-line installation (ie: without internet connectivity on your OpenStack servers), it becomes really horrible to setup all the mirrors.

This broken policy is one major blocker for me to even use OSA, and one good reason that makes me recommend against using it.

Is there a chance that we see the team changing this policy / way of installing things? Or am I mistaking that this is a mandatory thing in OSA maybe? If so, then I probably shouldn't have written the above, so please let me know.

Cheers,

Thomas Goirand (zigo)

On 6/1/23 07:42, Thomas Goirand wrote:

On 6/1/23 13:19, Dmitriy Rabotyagov wrote:

...

You can set `rabbitmq_install_method: distro` in user_variables and rabbitmq will get installed from distro-provided repositories rather then external ones: https://opendev.org/openstack/openstack-ansible-rabbitmq_server/src/branch/m...

But yes, default behaviour is to use external repos.

You're slightly wrong about reasons behind why this behaviour is default though. It's not about having "latest" versions, it's about having consistent/same versions across all distributions. First of all, then related bugs and security vulnerabilities are the same for all distros, so it's kinda easier to keep track on that. But then most important part is cross-distro installations. So let's assume an individual is running Ubuntu (or CentOS, doesn't matter), and they want to migrate to Debian. Having different rabbitmq versions installed by these distributions will totally be a blocker for such resilient migration. At the same time, when exactly the same versions of rabbit/erlang/galera are installed - they can just re-setup control planes one by one to another distro without any pain and the cluster will remain functional.

Hi Dmitriy,

Thanks for the explanation. It makes more sense now (even though I don't think there's many people willing to switch distro in an existing deployment).

Cheers,

Thomas Goirand (zigo)

Hello Thomas,

Yes you are bound to do it every few year when you need to upgrade the OS on your existing installation.

Thanks

Marc

even though I don't think there's many people willing to switch distro in an existing deployment

Oh, there were quite some migrations from CentOS once they announced their Stream approach. And who knows what the future prepares for us... This is also applicable btw for OS upgrades. Again, if we're talking about CentOS or Rocky, where you must re-install OS to majorly upgrade it - having versions synced makes it less painful to upgrade through re-install.

чт, 1 июн. 2023 г. в 13:50, Michał Nasiadka mnasiadka@gmail.com:

That’s the same reason for Kolla - we support multiple distros - so we try to have the same version across distributions to minimise differences - especially in RabbitMQ and MariaDB department.

As a user you can still override the Dockerfile templates and use the distro provided packages - but for the images published through OpenDev CI jobs - we’re publishing with packages from upstream RMQ/MariaDB repos.

Best regards,

Michal

...

On 1 Jun 2023, at 13:19, Dmitriy Rabotyagov noonedeadpunk@gmail.com wrote:

You can set `rabbitmq_install_method: distro` in user_variables and rabbitmq will get installed from distro-provided repositories rather then external ones: https://opendev.org/openstack/openstack-ansible-rabbitmq_server/src/branch/m... But yes, default behaviour is to use external repos.

You're slightly wrong about reasons behind why this behaviour is default though. It's not about having "latest" versions, it's about having consistent/same versions across all distributions. First of all, then related bugs and security vulnerabilities are the same for all distros, so it's kinda easier to keep track on that. But then most important part is cross-distro installations. So let's assume an individual is running Ubuntu (or CentOS, doesn't matter), and they want to migrate to Debian. Having different rabbitmq versions installed by these distributions will totally be a blocker for such resilient migration. At the same time, when exactly the same versions of rabbit/erlang/galera are installed - they can just re-setup control planes one by one to another distro without any pain and the cluster will remain functional.

чт, 1 июн. 2023 г. в 13:00, Thomas Goirand zigo@debian.org:

...

On 5/28/23 02:27, Dmitriy Rabotyagov wrote:

...

That is just ridiculous... We have just switched from cloudsmith because it's rotating packages too aggressively...

IMO, what's ridiculous, is to insist using upstream broken-by-design repositories for each-and-every-component (this event illustrate it well...), just because you want the latest upstream release of everything for no valid reason (as if what was released 2 weeks ago is not relevant anymore...).

On the specific case of RabbitMQ, this means using the upstream repo version of erlang, meaning that everything else that is packaged in the distro that uses erlang is broken.

If there was any valid reason to do a backport of a component in stable-backports (for Debian), or even if it was a personal preference of the OSA team, I would have happily done the work. Though never ever, the OSA / Kolla team got in touch with me for this kind of things.

Another issue is that, if you want to do an off-line installation (ie: without internet connectivity on your OpenStack servers), it becomes really horrible to setup all the mirrors.

This broken policy is one major blocker for me to even use OSA, and one good reason that makes me recommend against using it.

Is there a chance that we see the team changing this policy / way of installing things? Or am I mistaking that this is a mandatory thing in OSA maybe? If so, then I probably shouldn't have written the above, so please let me know.

Cheers,

Thomas Goirand (zigo)