Skip to content

Idempotency issue with implicitly enabled plugins #930

@wyardley

Description

@wyardley

rabbitmq_pluginwas retrieving a list of existing plugins by querying for "explicitly" enabled plugins using therabbitmq-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:

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.

Copied this text from @nmaludy's #844, but creating an issue as well, just for tracking purposes.

This also implements a different fix for what was originally fixed in #909

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions