There was a typo in actions.yaml for the resume action that was breaking
builds. This change fixes that typo. The charm will build.
Closes-Bug: 2030677
Change-Id: I2fb654eb176318e9e72e84bf41650e878b989528
Add the 'docs' key and point it at a Discourse topic
previously populated with the charm's README contents.
When the new charm revision is released to the Charmhub,
this Discourse-based content will be displayed there. In
the absense of the this new key, the Charmhub's default
behaviour is to display the value of the charm's
'description' key.
Change-Id: Idd4eb37dd413b49a99b8b81fd15d0b45f75ae97e
Drop configuration key 'source' override in rabbitmq-server and
mysql-innodb-cluster applications.
Add bindep.txt to install package dependencies needed to run unit tests.
Related-Bug: #1991528
Change-Id: I345e3bb7be7492286daf9e5ab36506915f3daab9
This patch adds the service user rotation feature, which provides two
actions:
- list-service-usernames
- rotate-service-user-password
The first lists the possible usernames that can be rotated. The
second action rotates the service, and is tested via the func-test-pr.
Change-Id: Ia94ab3d54cd8a59e9ba5005b88d3ec1ff87019b1
func-test-pr: https://github.com/openstack-charmers/zaza-openstack-tests/pull/1029
Add 23.04 run-on base and add lunar to metadata.yaml.
Drop 22.10 run-on base and drop kinetic from metadata.yaml.
Charm-helper sync to pick up Antelope support.
Change-Id: I8a4f42249a8607c5d0baf3b9f19d8edd663ec1ca
It removes the necessity to run the cron task as root user
and ensure the content created in /var/lib/rabbitmq belongs
to rabbitmq user and group solely.
Then giving access for nrpe user is done by adding its user
to rabbitmq group.
Also implemented in the upgrade-charm hook for ongoing
deployments
Closes-Bug: #1879524
Change-Id: I19e3d675ace7c669451ca40a20d21cef1aec6a95
The beam.smp process won't start if more than 1024 are configured, the
charm could make this by default on large systems (e.g. more than 42
CPUs). This change makes RabbitMQEnvContext.calculate_threads() never
return more than 1024 (MAX_NUM_THREADS).
Change-Id: I92879445210bac6ee7d96a704cdf428ca738e3b6
Closes-Bug: #1768986
This is a fix/workaround to the package upgrade bug that affects the
charm. The post-inst package script updates the .erlang.cookie if it is
insecure during the upgrade of rabbit from 3.8 to 3.9. This breaks the
series-upgrade resulting in a charm erroring on the post-series-upgrade
hook.
This fix works by checking if the .erlang.cookie has changed during the
post-series-upgrade hook and either updating the cookie in peer storage
(if it is insecure) or ensuring that the cookie from peer storage is
written to the .erlang.cookie if it isn't the leader. This ensures that
the cluster continues to work and that the series-upgrade can be
completed across the cluster.
Change-Id: I540ea8da85b3b4326ccb8194f1d8b1050b04eae9
Closes-Bug: #2006485
Add 22.10 run-on base and add kinetic to metadata.yaml.
Sync charm-helpers to pick up kinetic support.
Change-Id: I26aaceb01f16ddb31123a37454a9cf0d61ed384c
upgrade-charm bash script was only executed and the hook
from rabbitmq_server_relations.py was silently ignored
This corrects at the same time a failure in the hook if
rabbitmq deployment was from a single unit without any
cluster.
Closes-Bug: #1993100
Change-Id: Iaf88d18d26a1cde23397a097fcd98b09a0a98846
Due to the @cache decorator in the code, it was possible to get the
charm into a state where RMQ is clustered, but the charm doesn't record
it. The charm 'thinks' it is clustered when it has set the 'clustered'
key on the 'cluster' relation. Unfortunately, due to the @cached
decorator it's possible in the 'cluster-relation-changed' hook to have a
situation where the RMQ instance clusters during the hook execution and
then, later, when it's supposed to writing the 'clustered' key, it reads
the previous cached value where it wasn't clustered and therefore
doesn't set the 'clustered' key. This is just about the only
opportunity to do it, and so the charm ends up being locked.
The fix was to clear the @cache values so that the nodes would be
re-read, and this allows the charm to then write the 'clustered' key.
Change-Id: I12be41a83323d150ba1cbaeef64041f0bb5e32ce
Closes-Bug: #1975605
* unpin the requires for pip, virtualenv and setuptools
* remove the pip.sh installer file.
* split the passenv to to have a var on each line (overcomes new ','
requirement).
* switch charm-tools to 2.8.4 to remove ruamel requirement that doesn't
work on Python 3.10
Change-Id: I44849aac8ead5e3e660ccd9d1305cc991461d02d
This change reconfigures the bundles to use OpenStack yoga, they are the
last version that support Focal and Jammy.
Change-Id: Ia54bfacee6635c1e85a0c97e22bc2a5974bda7d1
Closes-Bug: #1991528
This reverts commit c0beec6fa2.
Reason for revert: I think this should be reverted as it removes focal support from the rabbitmq-server master, and thus this won't cherry-pick cleanly to the stable/jammy channel for the 3.9 track.
Change-Id: Iebab77fcc0cee31af66980c2d3be334fffe06222
* sync charm-helpers to classic charms
* change openstack-origin/source default to zed
* align testing with zed
* add new zed bundles
* add zed bundles to tests.yaml
* add zed tests to osci.yaml and .zuul.yaml
* update build-on and run-on bases
* add bindep.txt for py310
* sync tox.ini and requirements.txt for ruamel
* use charmcraft_channel 2.0/stable
* drop reactive plugin overrides
* move interface/layer env vars to charmcraft.yaml
Change-Id: I93da9ce52bed2b3e8a467491d2a61bfd2ed4ea7d
For units deployed before the implementation of the
cluster-partition-handling strategy they won't have that key set in the
leader making the charm believe there are pending tasks, so this change
seeds the key when is not set with the value present in the charm's
configuration.
Change-Id: Ifdae35ffee1ad7a8f4e5248c817cca14b69d9566
Closes-Bug: #1979092
The CONFIG_FILES is not a constant, its a method and when this
is passed to the ConfigRenderer it will cause a failure because
the items() function does not exist (since its not a dict).
Change-Id: Ice6cce6a736d96883eb8bc003852c2df60af7c62
Closes-Bug: 1971451
RabbitMQ sesrver sometimes creates non-uniform outputs that nrpe
can't parse. Instead of breaking the check, this commit outputs
the error messages and continue the check.
This problem is most likely caused by queue state being
"down" [1]. However, because the current charm doesn't show such
information and the bug is hard to manually reproduce, this
commit adds the state attribute when creating queue_state file
for future debugging.
[1] https://www.rabbitmq.com/rabbitmqctl.8.html#state_2
Closes-Bug: #1850948
Change-Id: Iaa493c8270f344cde8ad7c89bd2bb548f0ad71bd
Remove legacy checks from set_ha_mode in rabbit_utils.py as it checks
for versions of rabbitmq which is less than version 3.0.0 which is not
available in the archives for any supported releases.
Change-Id: Ib21f6ae3f30eabaaa8d677c20a555ded4e6851d6
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
The nrpe charm doesn't support jammy yet, which is a problem because it
is a subordinate charm. Drop it from the test bundles for the time being
and when this is resolved, it will be added back in.
Change-Id: Id54c0d145fb111914a38e9ed5776712ec6a92f87
Use the coordination module when cluster join events are called.
The `cluster_wait` method has been removed as it is no longer used
and `cluster_with` has been broken up into three new methods (
`clustered_with_leader`, `update_peer_cluster_status` and
`join_leader`) which can be called separately. The `modulo-nodes`
and `known-wait` charm options have been removed as they are no
longer needed.
Closes-Bug: #1902793
Change-Id: I136f5dcc855da329071e119b67df25d9045e86cc
Use the coordination module to manage package upgrades across the
cluster. To each this some of the setup was moved into a new
configure_rabbit_install method which handles setup is normally
run after an upgrade.
Change-Id: I8d244d96c83a5da164322faff873a72530ec9def
Use the coordination module to manage restarting the rabbitmq
services. This is to ensure that restarts are only
performed on one unit at a time. This helps prevent
situation which can cause the cluster to become split
brained (eg if two or more nodes are restarted at the same
time).
* Manually run _run_atstart & _run_atexit method when actions
are run as this does not happen automatically and is needed by
the coordination layer.
* Replace restart_on_change decorator with
coordinated_restart_on_change. coordinated_restart_on_change
includes logic for requesting restart locks from the coordination
module.
* The coordination module works via the leader and cluster events so
the hooks now include calls to check_coordinated_functions
which will run any function that is waiting for a lock.
* Logic has been added to check for the situation where a hook is
being run via the run_deferred_hooks actions. If this is the
case then restarts are immediate as the action should only be run
on one unit at a time.
Change-Id: Ia133c90a610793d4da96d3400a3906b801b52b73
This update is to ensure that the Zuul Canonical CI builds the charm
before functional tests and ensure that that artifact is used for the
functional tests. This is to try to ensure that the charm that gets
landed to the charmhub is the same charm that was tested with.
Change-Id: I3cb1f519e8f1d6765b41751994633be73e5bdea5
Charmhelpers directory was missed in the conversion to the charmcraft
way of building charms. The rabbit charm has a slightly different
location for charmhelpers than other charms. Add charmhelpers to
charmcraft.yaml to ensure it is packed in the charm file.
Change-Id: I72155c4bd2ace7497d59eeec3552985aec39d44b
Closes-Bug: #1960769