GitHub puppet-rabbitmq
168
168
31
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

[WIP] Add CentOS/RHEL 8 Support
enhancement

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 CentOS/RHEL 8 Support
enhancement

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 CentOS/RHEL 8 Support
enhancement

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 CentOS/RHEL 8 Support
enhancement

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 CentOS/RHEL 8 Support
enhancement

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

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

rabbitmq_plugin now correctly detects implicitly enabled plugins
bug

…reserve idempotency regardless of plugin install order

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

rabbitmq_plugin now correctly detects implicitly enabled plugins
bug

…reserve idempotency regardless of plugin install order

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

rabbitmq_plugin now correctly detects implicitly enabled plugins
bug

…reserve idempotency regardless of plugin install order

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

Change repos_ensure default from false to true
backwards-incompatible

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!

Change repos_ensure default from false to true
backwards-incompatible

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!

Change repos_ensure default from false to true
backwards-incompatible

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!

Change repos_ensure default from false to true
backwards-incompatible

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!

Refactor manifests
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 support for RHEL/CentOS 8
enhancement
tests-fail
needs-feedback

Fixes #816

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.

Add support for multiple LDAP servers
enhancement
needs-tests

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.

Add auto cluster configuration support
needs-rebase
tests-fail
merge-conflicts
  • 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
-->