GitHub puppet-rabbitmq

RabbitMQ Puppet Module

Pull Request (PR) description

Changed regex for rabbitmq_queue parameter.
Queues and vhosts are able to have spaces in their names, so the regex is to restrictive.

Pull Request (PR) description

This removes the superfluous daemon-reload code in this module.

The upstream module (https://github.com/camptocamp/puppet-systemd) removed the support for puppet 4 and 5 that made this reload construct necessary.

They removed their code in this PR: https://github.com/camptocamp/puppet-systemd/pull/171

On the other hand, https://github.com/voxpupuli/puppet-rabbitmq/pull/884 doesn't go far enough, as it simply raises the possible version of the systemd module without taking into account the EOL of Puppet 4 and 5.

This Pull Request (PR) fixes the following issues

Fixes #875

Cheers
Thomas

<!--
Thank you for contributing to this project!

• This project has a Contributor Code of Conduct: https://voxpupuli.org/coc/
• Please check that here is no existing issue or PR that addresses your problem.
• Our vulnerabilities reporting process is at https://voxpupuli.org/security/

-->

Pull Request (PR) description

1. Adds the option for client_renegotiation to rabbitmq config
2. Copies multiple options from rabbitmq config to management plugin config similar to existing ssl settings
   • client_renegotiation
   • secure_renegotiate
   • reuse_sessions
   • honor_cipher_order
3. Wraps client_renegotiation and secure_renegotiate in a conditional to not include them when enabling TLSv1.3 as they are incompatible
4. Updates/add tests for client_renegotation setting and TLSv1.3 conditional

This Pull Request (PR) fixes the following issues

Pull Request (PR) description

Previously, rabbitmq_plugin was retrieving a list of existing plugins by querying for "explicitly" enabled plugins using the rabbitmq-plugin -E command. This caused us issues when adding support for CentOS/RHEL8 where we noticed that in this mode, ordering of plugins matters.

Example of the scenario we saw:

In this spec test: https://github.com/voxpupuli/puppet-rabbitmq/blob/master/spec/acceptance/parameter_spec.rb#L18

The following plugins are declared:
puppet
rabbitmq_plugin { [ 'rabbitmq_federation_management', 'rabbitmq_federation' ]:
ensure => present
}


The rabbitmq_federation_management plugin depends on rabbitmq_federation, so when our code enables rabbitmq_federation_management it will automatically enable rabbitmq_federation, but mark it as being "implicitly" enabled because it was enabled as a result of enabling rabbitmq_federation_management.

Then, when go to query for the list of enabled plugins using the -E option, this only lists our "explicitly" enabled plugins, so rabbitmq_federation is never listed and every time we run Puppet it attempts to enable the plugin, breaking idempotency.

The fix

The rabbitmq-plugin command has two options -E to list only "explicitly" enabled plugins and -e to list both "explicitly" and "implicitly" enabled plugins. The fix was simply to switch to this other flag. Along the way i refactored the code to reduce duplication and added lots of unit tests for more test coverage.

References

For more info you can see the CentOS/RHEL 8 PR where this was discovered: https://github.com/voxpupuli/puppet-rabbitmq/pull/842

Pull Request (PR) description

The packagecloud repo was enabled by default in old releases but it was disabled by https://github.com/voxpupuli/puppet-rabbitmq/pull/493 .
Now we need this repo to support CentOS 8 , and we discussed this behavior and agreed this should be enabled by default.
Further details can be found in https://github.com/voxpupuli/puppet-rabbitmq/pull/900 .

This Pull Request (PR) fixes the following issues

N/A