charm-rabbitmq-server:stable/bionic

Last commit made on 2021-10-21
Get this branch:
git clone -b stable/bionic https://git.launchpad.net/charm-rabbitmq-server

Branch merges

Branch information

Name:
stable/bionic
Repository:
lp:charm-rabbitmq-server

Recent commits

b3adbfd... by Alex Kavanagh

21.10 - Release

Remove the "channel: candidate" from the func-test
bundles.

Change-Id: I4f5f80ef44d431e0b478fca53fa7edb69c39a959

657c89c... by Alex Kavanagh

21.10 - Stable cut of charms for testing period

* use stable/21.10 libraries
* use zaza/zaza-openstack-tests at stable/21.10
* build.lock files for reactive charms
* bundles refer to ~openstack-charms candidate channel

Change-Id: I6f5c6fdb5b381a074d9e79468ff70dcc46517828

bfcc469... by Alex Kavanagh

Add xena bundles

- add non-voting focal-xena bundle (unused in gate)
- add non-voting impish-xena bundle
- charm-helpers sync for new charm-helpers changes
- update tox/pip.sh to ensure setuptools<50.0.0

Change-Id: Ic552eff1daa9739ad7fd46af4f7c143f0c9062ea

242167b... by Julien Thieffry

Display busiest queues in check_queues NRPE plugin

When invoking the check_rabbitmq_queues script with wildcards for vhost
and/or queue parameters, script output does not reflect precisely which
queues are having a high number of oustanding messages as information is
consolidated under the wildcard.

This change fixes this behaviour by adding a new charm configuration
parameter which allows the user to specify the number of busiest queues,
n, to display should the check_rabbitmq_queues script reports any
warnings or errors. The default, n=0, keeps the current script output.
This option is applicable regardless of the vhost:queue combination but
is specifically relevant when wildcards are passed as arguments.

Implementation displays the first n items in the stats list re-organized
in decreasing message count order.

Closes-Bug: #1939084
Change-Id: I5a32cb6bf37bd2a0f30861eace3c0e6cb5c2559d

fd8d018... by Billy Olsen

Move cron max file age calculation to rabbit_utils

The check_rabbitmq_queues nrpe check accesses the cron file created
for running collect stats job. This is done in order to determine if
the stats are too old and an alert should be raised. The nagios user
does not have access to read the cron job when running in a hardened
environment where /etc/cron.d is not readable.

This change refactors this logic to move the calculation of maximum
age for a stats file from the check_rabbitmq_queues script and into
the rabbit_utils code where it is generating the nrpe configuration.
A new (optional) parameter is added to the check_rabbitmq_queues
script to accept the maximum age in seconds a file can last be
modified.

This change also removes the trusty support in hooks/install and
hooks/upgrade-charm as the rabbit_utils.py file needs to import a
dependency which is installed by the scripts. It is cleaned up to make
sure the croniter package is always installed on install or upgrade.

Change-Id: If948fc921ee0b63682946c7cc879ac50e971e588
Closes-Bug: #1940495
Co-authored-by: Aurelien Lourot <email address hidden>

8948fe7... by Zuul <email address hidden>

Merge "Add config parameters to tune mnesia settings"

dcf0ef0... by Zuul <email address hidden>

Merge "Improve parsing of cron schedule"

e7dc8b5... by Zuul <email address hidden>

Merge "Add Hirsute to the test gate"

45ded8b... by Billy Olsen

Improve parsing of cron schedule

Improving the parsing of the cron schedule for /etc/cron/rabbitmq-stats.
The code makes assumptions that the user in the cron entry will be the
root user, which is generally safe as that's what the charm applied.
However, the parsing is brittle in that it depends on the 'root' string
in the entry. This changes the code so that the cron timer spec is
stripped out based on the column entries in the file.

Change-Id: I2d573e8942e840e0e5376f1537a2a3373fea3db8
Fixes-Bug: #1939702

8015d9a... by Nicolas Bock

Add config parameters to tune mnesia settings

When a RabbitMQ cluster is restarted, the mnesia settings determine
how long and how often each broker will try to connect to the cluster
before giving up. It might be useful for an operator to be able to
tune these parameters. This change adds two settings,
`mnesia-table-loading-retry-timeout` and
`mnesia-table-loading-retry-limit`, which set these parameters in the
rabbitmq.config file [1].

[1] https://www.rabbitmq.com/configure.html#config-items

Change-Id: I96aa8c4061aed47eb2e844d1bec44fafd379ac25
Partial-Bug: #1828988
Related-Bug: #1874075
Co-authored-by: Nicolas Bock <email address hidden>
Co-authored-by: Aurelien Lourot <email address hidden>