Open Stack

> 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 at 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 at 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/master/releasenotes/notes/rabbitmq-using-external-repo-instead-of-pkg-file-8cdd00f58d3496ba.yaml
> > 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 at 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)
> >>
> >>
> >
>