rabbit_plugins: Filter non-plugins out #2212
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Once merged and CI'd, this change should be backported to 3.8.x and 3.7.x to keep the behavior consistent accross branches. |
When the module discovers plugins in the plugins directories, it
considers all applications there. There are actual RabbitMQ plugins,
their dependencies, and possibly other applications which are neither
plugins nor dependencies.
So far, this was the case of `syslog` which could be used by Lager if
the user configures it. To make sure `rabbit_plugins` or
rabbitmq-plugins(8) didn't mess with `syslog`, there was a hard-coded
filtering function which excluded this specific application.
In RabbitMQ Enterprise Edition, we want to add another application
of this kind: `inet_tcp_compress_dist`. This application implements
an Erlang distribution protocol, so it is effectively unrelated to
RabbitMQ. However, to keep packaging simple, it is provided in the
plugins directory.
We could add it to the hard-coded filtering function, but instead this
function is replaced by the following logic to filter plugins:
* Applications which depend on `rabbit` are considered actual plugins.
* Plugins' dependencies, direct and indirect, are considered plugins
as well.
Therefore, `rabbit_plugins` will ignore:
* Applications which don't depend on `rabbit` and no plugins
depend on them (again, directly or indirectly)
* Applications which are part of Erlang/OTP.
This means the behavior slightly changes: a plugin which didn't declare
its dependency to `rabbit` will not be considered a plugin anymore. I
consider it is a bug in the plugin in the first place.
The code will log the following debug messages to list ignored
applications:
2020-01-14 13:18:41.468 [debug] <0.941.0> Plugins discovery: ignoring getopt, not a RabbitMQ plugin
2020-01-14 13:18:41.468 [debug] <0.941.0> Plugins discovery: ignoring inet_tcp_compress_dist, not a RabbitMQ plugin
2020-01-14 13:18:41.468 [debug] <0.941.0> Plugins discovery: ignoring lz4, not a RabbitMQ plugin
2020-01-14 13:18:41.468 [debug] <0.941.0> Plugins discovery: ignoring syslog, not a RabbitMQ plugin
2020-01-14 13:18:41.468 [debug] <0.941.0> Plugins discovery: ignoring zstd, not a RabbitMQ plugin
dumbbell
force-pushed
the
filter-non-plugins-out
branch
from
9ac501e
to
b07cf2d
Compare
|
I have already tested this in the context of cc @michaelklishin for visibility |
gerhard
approved these changes
Jan 16, 2020
|
Thank you! |
dumbbell
added a commit
to rabbitmq/rabbitmq-cli
that referenced
this pull request
Jan 16, 2020
They should depend on `rabbit`, not on `rabbit_common`. This will be even required #rabbitmq/rabbitmq-server#2212 is accepted.
dumbbell
added a commit
that referenced
this pull request
Jan 16, 2020
It should depend on `rabbit`. This will be even required once ##2212 is accepted.
dumbbell
added a commit
that referenced
this pull request
Jan 17, 2020
Those plugins are created at runtime. We just need to populate the list of `applications` they depend on. This list must include `rabbit`. This will be even required once ##2212 is accepted.
pjk25
added a commit
that referenced
this pull request
Jan 23, 2020
Bundle the commits associated with #2212 for the purpose of backporting
pjk25
added a commit
that referenced
this pull request
Jan 23, 2020
Bundle the commits associated with #2212 for the purpose of backporting
pjk25
pushed a commit
to rabbitmq/rabbitmq-cli
that referenced
this pull request
Jan 23, 2020
They should depend on `rabbit`, not on `rabbit_common`. This will be even required #rabbitmq/rabbitmq-server#2212 is accepted. (cherry picked from commit be5f8ac)
pjk25
pushed a commit
to rabbitmq/rabbitmq-cli
that referenced
this pull request
Jan 23, 2020
They should depend on `rabbit`, not on `rabbit_common`. This will be even required #rabbitmq/rabbitmq-server#2212 is accepted. (cherry picked from commit be5f8ac)
|
Backported to |
pjk25
pushed a commit
to rabbitmq/rabbitmq-monorepo
that referenced
this pull request
Sep 9, 2020
They should depend on `rabbit`, not on `rabbit_common`. This will be even required #rabbitmq/rabbitmq-server#2212 is accepted. (cherry picked from commit cccf81d)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When the module discovers plugins in the plugins directories, it considers all applications there. There are actual RabbitMQ plugins, their dependencies, and possibly other applications which are neither
plugins nor dependencies.
So far, this was the case of
syslogwhich could be used by Lager if the user configures it. To make surerabbit_pluginsor rabbitmq-plugins(8) didn't mess withsyslog, there was a hard-coded filtering function which excluded this specific application.In RabbitMQ Enterprise Edition, we want to add another application of this kind:
inet_tcp_compress_dist. This application implements an Erlang distribution protocol, so it is effectively unrelated to RabbitMQ. However, to keep packaging simple, it is provided in the pluginsdirectory.
We could add it to the hard-coded filtering function, but instead this function is replaced by the following logic to filter plugins:
rabbitare considered actual plugins.Therefore,
rabbit_pluginswill ignore:rabbitand no plugins depend on them (again, directly or indirectly)This means the behavior slightly changes: a plugin which didn't declare its dependency to
rabbitwill not be considered a plugin anymore. I consider it is a bug in the plugin in the first place.The code will log the following debug messages to list ignored applications: