The config options `module-nodes` and `known-wait` are no longer used
after commit 12de0d964c introduced
coordinated restarts across the rabbit cluster. This change removes
those charm config options.
Change-Id: I3aee35633e0716f8ce933ee3079494dbc761c04d
Over time the managment plugin has become a core part of managing
a rabbit deployment. This includes allowing tools such as nrpe to
be able to query the api and alert for situations such as orphaned
queues.
Change-Id: Icbf760610ce83b9d95f48e99f6607ddf23963c97
Partial-Bug: 1930547
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
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 <nicolas.bock@canonical.com>
Co-authored-by: Aurelien Lourot <aurelien.lourot@canonical.com>
* Make TLS simpler and more accurate.
* Apply README template.
* Adjust config.yaml re use of Vault.
Related-Bug: #1871442
Change-Id: Ia819cb03d30f6b4e0a04cc388e7243849800455a
Option '-e <vhost> <queue>' was added to the 'check_rabbitmq_queues.py'
nrpe script to allow excluding selected queues when checking queue
sizes. Corresponding option 'exclude_queues' was added to the
charm config.
By default, following queues are excluded:
* event.sample
* notifications_designate.info
* notifications_designate.error
* versioned_notifications.info
* versioned_notifications.error
Closes-Bug: #1811433
Change-Id: I57e297bb4323a3ab98da020bfcb1630889aac6d7
queue-master-locator is a configuration option supported by
rabbitmq-server since 3.6, it allows to have control of where the
master queue will be created.
Change-Id: I38cc019b73d062572e19bd532b6bccdaf88638ba
Func-Test-PR: https://github.com/openstack-charmers/zaza-openstack-tests/pull/382
Closes-Bug: #1890759
Signed-off-by: Nicolas Bock <nicolas.bock@canonical.com>
Make the rabbitmq queue check also check if its input data file was
recently updated. This input data is created via cronjob; if that gets
stuck we might not actually be getting meaningful data.
The charm supports configuring the check interval via a full cron time
specification, so technically one could have that updated only once a
year even if this doesn't make much sense in a monitoring scenario.
Also fix a buglet in the nrpe update hook function: only deploy a
queue check if the cron job hasn't been deconfigured by setting it to
the empty string
Change-Id: I60141397f39e3b1b0274230db8d984934c98a08d
Closes-Bug: #1898523
Adds monitoring options to allow us to check for vhosts in addition to
the host specific one made by default, when using the nrpe subordinate.
Change-Id: I10715e8ab8c83fdd7d5c08736ee89472acfe3933
Related-Bug: 1730507
As per team discussion, Vault is the preferred method for SSL
management and Network spaces should not be mentioned in any
README pending a supporting documentation effort.
Change-Id: If8bc2f271be71caccd4f3f0b50f8ae412bef35b7
This commit clarifies syntax and semantics of the queue thresholds.
* both yaml multi-line arrays and lists of lists are supported
* explain that the order of the values does matter, especially if using
wildcards
Change-Id: I31ff1bfa94a708a4f7469bb3a9a5dbca33bb3607
Closes-Bug: 1822547
By setting the default to 'autoheal', we can better ensure
service continuity in most use-cases. With autoheal, the
'winning' partition will be the one with the most clients
connected to it and nodes in the losing partition(s) will be
restarted.
Change-Id: I0988e1d22e7c97819552b3bf325801632b099a32
Closes-Bug: 1802315
OpenStack charms currently unconditionally enable notifications
for consumption by aodh/ceilometer etc... If these services are
not deployed, then notification queues will fill over time and
cause alerts/service issues.
Workaround this issue for now by setting a TTL on notification
topics under the openstack vhost (if configured).
By default, the TTL for messages in any notification topics will
be set to 1 hour, after which they are dropped from the queue.
Change-Id: I46a11e98a2e3bbb6016e7ddfe27bdffe55c37aab
Partial-Bug: 1737170
In this charm we run a cron job to check rabbitmq status and it is
possible that the commands run could fail or hang if e.g. rabbit
is not healthy. Currently the cron will never timeout and could
hang forever so we add a new timeout config option 'cron-timeout'
which, when set, will result in the a SIGINT being sent to the
application and if that fails to exit within 10s a SIGKILL is sent.
We also fix logging so that all output goes to syslog local0.notice.
Change-Id: I0bb8780c5cc64a24384648f00c8068d5d666d28c
Closes-Bug: 1716854
Random waits were used to avoid restart collisions. This change uses
distributed_wait based on modulo_distribution to calculate wait time
based on the modulo-nodes setting (or peer relations) and known-wait.
charm-helpers sync for module distribution helpers
Depends-On: I02c648cccc72d816beeec5546b6c7914d57c607a
Change-Id: Ic796c23e1bc560d461c674cbfadf8589380eb649
As config-changed hook runs each time jujud is restarted, the hook
could upgrade rabbitmq without operator warrant.
This change runs apt-get update/upgrade in config-changed only
if "source" charm options is changed.
Change-Id: I56781659b02b883c9b15867dac6f9c8d27b5d975
Closes-Bug: 1694377
The description for this option is confusing. Leaving it unset
implies using the default value which enables the cron task.
This change clarifies to the user they must actually set the value to
an empty string in order to disable the cron task.
Change-Id: I39efdfe574412ec5a188794b32b5cf221c40e884
Closes-Bug: #1697523
Adds connection-backlog and erl-vm-io-thread-multiplier config
options which are required for tuning when deploying in
environments with large numbers of clients and server hosts
with high numbers of cores respectively. Also refactors
rabbitmq-env.conf rendering code so that it is properly
applied by the charm.
Change-Id: I8596eb9a0419d4e64782bfaf9d8c0f67e5de96b1
Closes-Bug: 1693561
Re-order settings based on section and move
HA options to bottom and mark as deprecated
since they and their related code is due
for imminent removal (has been deprecated
for several cycles now) and should not be
used.
Change-Id: Ic13897a2c8fd97cfb98454375d7325a018c5b37d
Make sure network-get is consulted when selecting an IP address. Generalize
the get_unit_ip to work with any relationship. Allow for cluster-network
override.
Change-Id: I75e9199ae586f663313f0c751247e1465c753a64
Partial-Bug: #1657305
Add charmhelpers.contrib.hardening and calls to install,
config-changed, upgrade-charm and update-status hooks.
Also add new config option to allow one or more hardening
modules to be applied at runtime.
Change-Id: I035d8d959f5217801b296a4975fce605b25b4b24
Billy Olsen