openstack/openstack-ansible-rabbitmq_server - openstack-ansible-rabbitmq_server - OpenDev: Free Software Needs Free Tools

Change-Id: I3c2751da86492c8659252cf5d7b691ce2cc111cf

Since ansible-core 2.10 it is recommended to use modules via FQCN
In order to align with recommendation, we perform migration
by applying suggestions made by `ansible-lint --fix=fqcn`
Change-Id: Id8a34727251ade1a1b2d5a881e5ee5e808b495dc

In order to reduce divergance with ansible-lint rules, we apply
auto-fixing of violations.
In current patch we replace all kind of truthy variables with
`true` or `false` values to align with recommendations along with
alignment of used quotes.
Change-Id: Ie295a52b403df4d404bf984fe0296d5be110f532

Depends-On: https://review.opendev.org/c/openstack/openstack-ansible/+/939824
Change-Id: Iba67d3e321c6ebc256bb63de27ce61c26db10ab0

The service is unconditionally stopped during the upgrade
prep tasks. There are several conditions that will notify
the handler to restart the service, such as updating the
config file or installing a new version of the rabbitmq
package. It is possible that none of these things happen
resulting in the service not being restarted during an upgrade.
This patch ensures that the service is always restarted
during an upgrade by notifying the restart handler when
the service is sucessfully stopped in the upgrade prep tasks.
Change-Id: I9fbe7806b3531921b90ac91c17b6a07deca2a4d2

There is currently a mismatch between the apt pin priorities for the
erlang and server rabbitmq repos. This patch sets the pinning to be
the same.
This should not affect normal package installation as recent changes
to this role require installation of a specific version and will
fail "safe" should that be unavailable. The intention with this patch
is to ensure that the behaviour is the same for both the erlang
and server repos in an abnormal situation where the installation
might fail.
Change-Id: I0d988572a102ca148059d198379d2a3115ecb795

With ansible-core 2.16 a breaking changes landed [1] to some filters
making their result returned in arbitrary order. With that, we were
relying on them to always return exactly same ordered lists.
With that we need to ensure that we still have determenistic behaviour
where this is important.
[1] https://github.com/ansible/ansible/issues/82554
Change-Id: I9ca1c66f88e9beea0e2c5add30a356fb717cfcfa

Having rabbitmq_package_state latest by default is not always expected
as all other roles do respect defined `package_state` value.
Change-Id: I5bcc550419cfe6d51dfb73eb935a93b93e460068

We are aligned on used RabbitMQ/Erlang versions for quite a while
now so it makes sense to move version defenition to defaults
instead of carrying them separately per distro family.
Change-Id: I5ca75bf25d099260bc446a6b4f7d9be7a2bdde58

Depends-On: https://review.opendev.org/c/openstack/openstack-ansible/+/934042
Change-Id: I231ea65b5340c43bffb541ce23d3a8e600015c2d

This makes us possible to leverage version comparison instead of search.
This also might come handy in the future when we need to be more
specific of expected versions for upgrade process.
Change-Id: I7a132145bc781db999f82ecb192e6e1ecfc9c0ad

Due to historical reasons RabbitMQ operations, like start/stop/restart
were perfromed in tasks and triggered on changes.
As of today there seems to be no need in such approach and we can use
handlers instead.
It will also move some tasks, which intend to run when service is
running, to their own file. This also allows to run them once on cluster
rather then for each host.
We also merge set_cookie with post_install as there is no reason to
maintain the task in it's own file.
Change-Id: I222b9de3ca531724b05c7fa2cf032a3271055d64

We can simplify logic and re-use rabbitmq_cluster_state tasks to
fetch the current state of the cluster in a dictionary, which allows
to avoid unnecessary today parsing of rabbitmq output.
Change-Id: Ib99fcb1a3e0092bf96143435a0c876ab6f286f36

At the moment rabbitmq_upgrade will temporary stop all nodes in the
cluster, shortly disrupting operations.
This behavior is now changed to perform a regular rolling upgrade [1]
Community right now relying on the rabbitmq_upgrade variable to
"recover" the cluster state by basically re-bootstrapping the cluster.
Such behaviour should be implemented separately in a follow-up patch.
[1] https://www.rabbitmq.com/docs/upgrade#rolling-upgrade
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/931801
Change-Id: Ibb3fae0d85dc31237ce169bb4cde9551dd5cabb6

Change-Id: I377b26dab9c0939c5de701fef9ebf4d230e19701

As verification of the cluster state is generic action which needs
to be included and registered at different parts of the role, it
makes sense to include it separately and evaluate feature flag conditions
during tasks include
Change-Id: Ib00c5072a663cdccf05156badc43cab675e8de9f

We can replace shell with a simple command using json formatter,
which allows us to select only missing flags and enable them expclicitly
rather then enable all flags.
This also produces a better log, representing which flags were missing.
Change-Id: Idb5c02109458771853e0fdbc7f6bb27beaa731b4

Current behaviour with just pinning on Ubuntu/Debian leads to potential
situations, when there's no selected version available in repo to
proceed with what's available based on set priorities.
Instead, it might be worth to fail explicitly when requested version is
not available. This also aligns behaviour with EL distros.
Change-Id: Iad69cc4b5f8ca40246bcbc604e77eef7975eb104

At the moment rabbitmq_upgrade flag is being used on unhealthy
clusters to repair them. However with change [1] we've introduced
running this task standalone very early during the playbook.
In case cluster is unhelathy - there is no good way to repair it anymore
as
`rabbitmqctl cluster_status` might fail right away with.
So let's ignore failures at this point and run feature_flags only if
we were successfull on fetching the status.
[1] https://review.opendev.org/q/Idf33b6810e1afb3a89dad5e65a48e86ac0a58a67
Change-Id: Ie453f327850f9c9ae54823c17b0292517fa56a82

This reverts commit 29d276582c.
Reason for revert: Eventually the failure, which we were reported previously
was caused not by retries, but by the very early inclusion of the task
from the playbook, which needs to be handled differently. A follow-up
change is needed to address that.
Change-Id: Ib64ff19201944a8581953eed8579abb6c9d9c401

We do have a variable `rabbitmq_erlang_version_spec` which is applicable
only for Debian, while for EL the variable is only private.
This patch does some alignment on things:
* spec is replaced with just a version, as we don't need ternary logic
anymore.
* defenition of erlang version is unified across distros
Change-Id: Ic72212fa2d6df55f2f60d1d38c48310765442e51

Rabbitmq provide a new set of ppa fronted by Cloudflare, use those
instead of the previous one which is no longer mentioned in the
rabbitmq installation guide.
Change-Id: I6eff083b95b392e9f8a05f79ee2ec49705257a64

At the moment we fixup only x86_64 arch while there way more arches
in the wild. So it's worth to have a mapping for architectures in place
rather then maintain quite complex replaces.
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/930272
Related-Bug: #2081764
Change-Id: I471fc337c0f13a5b8b10131760ed96032a34f9e8

This is the latest minor version in 3.13 series. Current 3.13.3 does not
exist for noble causing it to install the latest, which is now 4.0
series
Change-Id: Ifaa69e8b9caa8d5dfa9f4b83db31932c82641a40

Instead of using a conditional block, use the "state" parameter
of the yum_repository module to ensure that the repo
config is correctly added/removed if rabbitmq_install_method is
changed after initial deployment.
Change-Id: Ief07a74cd0019fefd58e27fb8dc4299b99299f99

The apt-key module is deprecated so the code is refactored to allow
any of the deb822_repository features to used instead.
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible-apt_package_pinning/+/927903
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible-os_tempest/+/907886
Change-Id: I96f1f23d6a1cca223ad4fc48a1caa21833a98b22

As task is execured right after handlers execution, it would make sense
to add retries just in case cluster doesn't come up immediatelly back.
Change-Id: Ia26c3a9e9a7a39969a5b6450703c14aad4760eea

As we've backported feature flags enablement to previous releases,
there is expectation that at this point all missing flags were enabled
now.
With that there is no reason to run check each role run, except it is
an expected upgrade of rabbitmq, after which new flags might appear.
Change-Id: Ic004de1ea5d00965e5bebe50b4a93e247b82873d

Change-Id: I4d2bfe34eaddb5e8c8ac6a0ff714ee6da7b7467f

Stable feature flags must be enabled before upgrades to ensure
the service can still start. These additional tasks check for
any disabled feature flags and enable them. This is done
immediately after upgrades so that systems can run with them
enabled striaght away.
Closes-Bug: #2038818
Change-Id: I5211a30899f544a9f7e609e85551a92b245d25bf

Change-Id: Iddc69e81e1677efcd1930afb4dc3113596e9537b

Update the zed release notes configuration to build from
unmaintained/zed.
Change-Id: I220491d548f4fe1031e572de645962238a039207