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

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

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

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

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

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

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

When we do not need to install external GPG keys nor pin packages
to external sources when installation_method is set to distro.
Change-Id: I29bbcacd6ce06516f1ef34cf58da8cac8ef79ea8

This patch adds installation of "native" to EL repo (which actually
is "extras") that provides RabbitMQ and Erlang.
This behaviour would align EL with DEB systems in terms of "distro"
path.
Change-Id: Ifa197131dd010108f3a0745322b32de1fb08b813

My assumption is that this restart only exists for historical
reasons or in order to force client re-connection and
re-definition of queues to match this policy.
Unfortunately the current task only executes on a single RabbitMQ
node when part of a cluster, so it is ineffective in forcing
reconnection. From a brief review at least when shifting from
non-HA to HA this also isn't required as queues are immediately
updated to reflect the new policy.
Given no clear reason for the task to be present, I'm removing
it ahead of making changes to the default HA policy.
Change-Id: I956abe68d4d7921a4e87ae5a7694d49546bdde94

Policies were always applied to target `all` aspects and
there was no way to have them target only e.g. exchanges.
This can be important though, see [1].
This change enables the use of the apply_to parmeter via the existing
variables while maintaining `all` to be the default.
[1] https://www.rabbitmq.com/docs/parameters#how-policies-work
Change-Id: I61d68c630599b8ef2382663e8a37fdc456435c11

This task is no longer needed in recent releases of openstack-ansible.
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible-os_tempest/+/907886
Change-Id: I2190c16548fb44948a26ee2817d8f71fbe66be53

With update of ansible-lint to version >=6.0.0 a lot of new
linters were added, that enabled by default. In order to comply
with linter rules we're applying changes to the role.
With that we also update metdata to reflect current state.
Change-Id: I63f6a2c803370736e969aa3a4dea3ea959316def

Using 'always' tag in combination with condition depending on
variables is not always a good idea because these variables may not be
defined at the moment.
Currently, rabbitmq_server role cannot be executed with tag limit,
because task containing 'always' tag has a condition operating on
variable(s) that are registered only when 'rabbitmq-config' tag is being
used.
Change-Id: I7ef7b3fed79933b4c8bbc39a63ca6db54532e10e

This is removed in ansible 2.14.
Change-Id: I3149f3babe9acf8c5854982f2d8e1cbcc23371e1

This line snuck in with Ie2d656bc04ea600e35735a7a8630cadd915469b7
probably to bring it in line with other OSA roles, but should already
be covered by the distribution_major_version line above.
Change-Id: Ib47d6dd5eff0df89ccb23c4adb141c7a6a89d298

There is no need in using complicated shell for getting/grepping
for instaled rabbitmq version as this can be done in more neat way
with simple commad.
Alternative would be to gather package facts, but we may want not to
rely on facts caching and leave quering package managers.
Change-Id: Ieb858a7e850ec6b48989196392fb85a4b3c2a8a7

In order to pass check mode, we must retrieve current installed version
regardless of mode.
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible/+/837706
Change-Id: Ib6a3084a8f5afd3d045864d0853ebffa025329e0

Record for 127.0.1.1 is added by some distributions which makes
clustering fail, as Erlang port is binded to mgmt IP, while rabbit
expects to access it through $hostname, which would lead to 127.0.1.1.
At same time it's possbile to explicitly bind distribution port only
to single address. So we need to
ensure that hostname resolvs to mgmt IP and drop record for 127.0.1.1
Closes-Bug: #1960587
Change-Id: I907d4714319ac7134ede0dc62b51c1964b9befc5

With this patch we ensure that duplicated records are not
created with rabbitmq role if hosts file already contain
OSA managed block. Managing hosts still might be required for
role usage outside of the OSA so we workaround this usecase.
Change-Id: Ia20902f0ffe21ce563966fee4d233e5ec3afe3d9
Related-Bug: #1960587 

It appears that old repo must be removed explicitly and apt_repository
don't have an option for exclusive content when filename defined
So we need to drop old repo after switching to cloudsmith to avoid
fetching data from them and make repos clean during upgrade.
Change-Id: Iffb5dd5f9a1937825e2cc345b720d7af072608c1

Replace placing templates for systemd overrides with
systemd_service role, that will handle overrides for us in more
convenient and unified way.
Change-Id: I2759b1949e9ecc98953f414c6f9838aed7dd8499

Currently Debian Bullseye doesn't have erlang provided by external repos
So in order to update rabbitmq version used we need to implement
rabbitmq_erlang_install_method, so that we could use external rabbitmq
with distro provided erlang.
Hpefully that is temporary solution and erlang packages for bullseye
will be built one day.
Change-Id: I32256271759d26522c17fe14c75b41da4c86c31a

Switch to using cloudsmith repo as a source for rabbitmq and erlang.
This allows us to be consistent about repository that is
used across supported distributions along with switching from
unreliable erlang-solutions that tend to fail periodically.
Change-Id: Ia438ee3b0aa1ba95aff014776e936516b83181ec

Starting from RabbitMQ 3.7.0 it's recommended to use new-style
config which is simply an ini file.
It's easier to read and maintain config file in ini fromat rather then
in classic erlang.
At the same time we still keep old-style config as it might have settings
that are not supported in new-style config.
There're no evidences that used there options are still supported,
but it's worth deprecating them in follow-up patch anyway.
Change-Id: I239366ad4aa2bc7a02d826b6c2f94631f4b0e622

Use a first_found lookup instead of a with_first_found loop so that
the 'paths' parameter can be used.
This ensures that only vars from the role are included, and not vars
from a parent calling role. This can happen when a parent role has
a higher priority vars file available for inclusion than the role
it calls.
Change-Id: Ie2d656bc04ea600e35735a7a8630cadd915469b7