GitHub puppet-rabbitmq
169
169
36
RabbitMQ Puppet Module

Metadata Valid
No translation
Correct Puppet Version Range
Supported Puppet version range is %{PUPPET_VERSION_RANGE}
With Puppet Version Range
Puppet version range is present in requirements in metadata.json
With Operatingsystem Support
No translation
Supports Only Current Centos
No translation
Supports Latest Centos
No translation
Supports Only Current Debian
No translation
Supports Latest Debian
No translation
Supports Only Current Ubuntu
No translation
Supports Latest Ubuntu
No translation
In Modulesync Repo
No translation
In Plumbing
Is in plumbing
Has Secrets
Has a .sync.yml file
Synced
Has a .msync.yml file
Latest Modulesync
No translation
Has Modulesync
Is present in voxpupuli/modulesync_config/managed_modules.yml
Released
Is in modulesync_config and in forge releases.
Reference Dot Md
The repository has a REFERENCE.md. It needs to be generated / puppet-strings documentation is missing.

Open Pull Requests

Changed rabbitmq_queue regex
enhancement

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.

Change repos_ensure default from false to true
backwards-incompatible
tests-fail

Pull Request (PR) description

As part of the work i was doing to enable CentOS/RHEL 8 support in #842 i ran into an issue where EPEL no longer ships RabbitMQ packages. In that PR i had made some hacky fixes to enable the RabbitMQ repos, via the repos_ensure parameter, by default on that OS. After some discussions it was decided that we should instead, simply change the default value of repos_ensure to true on all OSes.

Note: This is a breaking change!

[WIP] Add CentOS/RHEL 8 Support
enhancement
merge-conflicts
tests-fail

Pull Request (PR) description

This PR adds support for installing RabbitMQ on CentOS 8 / RHEL 8.
Also added back into the README information to the end-user about the need to use an external erlang module on RHEL systems.

This Pull Request (PR) fixes the following issues

Fixes #816

Closes #826

Add support for RHEL/CentOS 8
enhancement
needs-feedback
tests-fail

Fixes #816

Refactor manifests
merge-conflicts
needs-work
tests-fail

The following classes still have to be refactored:
- [ ] config.pp
- [ ] server.pp
- [ ] repo/apt.pp
- [ ] repo/rhel.pp

The classes apt.pp and rhel.pp depend on pr #797.

I also need to know which Mirror we want to use as default and change the GPG key. I would like to use Bintray, because it provides packages for Erlang.

Because of the many changes to the code we will have to release a major release anyway.

Add auto cluster configuration support
merge-conflicts
needs-rebase
tests-fail
  • added clustername fact and spec tests for it
  • added rabbitmq_cluster type and provider with tests

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

-->

Pull Request (PR) description

<!--
Replace this comment with a description of your pull request.
-->

This Pull Request (PR) fixes the following issues

<!--
Replace this comment with the list of issues or n/a.
Use format:
Fixes #123
Fixes #124
-->

Add support for multiple LDAP servers
enhancement
merge-conflicts
needs-tests
tests-fail

The RabbitMQ LDAP plug-in supports multiple servers being listed in the the "servers" field, but the puppet module currently only accepts a single String value.

My simple pull request allows an array of servers to be passed, which is then correctly formatted in the rabbitmq.confg template. I additionally attempt to detect an array that has already been flattened to a string, as happens if you configure the ldapservers variable from hiera by way of sourcing an array variable that is already defined else where in puppet (rabbitmq::ldapserver: "%{ldap::servers}").

Tested and working with a string, an array, and a array flattened to a string.

Fix rabbitmq_plugin to correctly detect implicitly enabled plugins
bug

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