Allow making an implicitly enabled plugin explcit via rabbtimq-plugins enable

[philomory]

Is your feature request related to a problem? Please describe.

If you have previously enabled rabbitmq_shovel_management (say), then that will implicitly enable rabbitmq_management. This means that, if you use rabbitmq-plugins disable rabbitmq_shovel_management, the rabbitmq_management plugin will also be disabled.

This is fine, but if you want to disable only the rabbitmq_shovel_management plugin, keeping the rabbitmq_management plugin, there's not actually any way to do that right now. The intuitive thing (at least, to me) is to simply issue rabbitmq-plugins enable rabbitmq_management to make the rabbitmq_management plugin's enabled status explicit rather than implicit, prior to issuing rabbitmq-plugins disable rabbitmq_shovel_management. Unfortunately, this doesn't work: the rabbitmq-plugins command sees that the rabbitmq_management plugin is already enabled (although only implicitly) and declares "configuration unchanged".

Describe the solution you'd like

I would like it if rabbitmq-plugins enable <plugin name> made a plugin explicitly enabled, even if it had already previously been implicitly enabled.

Describe alternatives you've considered

Obviously, one could just allow the management plugin to become disabled automatically and then re-enable it afterwards. However, if you have automated systems accessing the management API, the downtime would be nice to avoid.

Additional context

This currently causes problems for the Puppet rabbitmq module; previously, it listed plugins with the -E flag, and thus if plugins were enabled "out of order" things would look permanently out of sync; more recently they've switched to listing with the -e flag, which solves the out of sync issue, but it means that, depending on the order in which plugins were initially enabled, later disabling one of them could lead to downtime (since Puppet will not notice that the action had unintended side effects, and correct them, until the next time it is applied).

[michaelklishin]

In this day and age, the absolute majority of automation tools pre-generate enabled_plugins files and do not use rabbitmq-plugins.

Chef and Puppet must be the only two open source holdouts that I can name. Given that their cookbooks/modules routinely restart nodes, I cannot think of a reason why either would absolutely have to use rabbitmq-plugins.

If any changes are introduced to the plugin states, I vote for removing the implicit state and only keeping disabled and enabled. But that won't even be noticed by some 99% of the users, so won't be a priority any time soon.

[philomory]

A perfectly reasonable (if mildly disappointing) answer. That said, this doesn't apply only to automation tools. Anyone enabling (or more specifically, disabling) plugins interactively via the command line would run into this as well. Whether that ever causes actual problems for anyone, I can't say.

In any case, I discovered that it's also possible to work around the issue with rabbitmq-plugins set <list of plugins>; this will explicitly enable any listed plugin, even if it was already explicitly listed.

[michaelklishin]

A couple of unusual behaviors of implicitly enabled plugins were discussed on the core team at least twice. The best option seems to be making all plugins "enabled", that is, eliminating the difference between explicitly and implicitly enabled plugin.

However, this idea pales in comparison to shipping 3.13 with Khepri and maturing Khepri-based RabbitMQ for 4.0 :(