Consider prepending a well known version-agnostic plugins directory to RABBITMQ_PLUGINS_DIR on Windows

[inikulshin]

1001 and #1016 introduced support for : (or ;)-separated path lists for RABBITMQ_PLUGINS_DIR. On Linux this includes automatically prepending /usr/lib/rabbitmq/plugins to the list of paths if RABBITMQ_HOME is set to a certain value.

The goal was to support a well known plugin directory path plus the installation root-specific one that might include version number. 3rd party plugins can therefore easily be placed into that directory by provisioning tools.

One thing that's missing for Windows compared to Linux is the prepended default value. Unfortunately it is less clear what directory can be used given that paths on Windows are a lot less standardized.

[michaelklishin]

We will not be changing the name, it's has been around for years.

Support for multiple directories was introduced in https://github.com/rabbitmq/rabbitmq-server/pull/1016 and did not include any Windows support. I wouldn't be surprised if that's still the case because no one asked for it.

[inikulshin]

Another suggestion, you'll probably reject because "it's has been around for years", is to add new environment variable for 3rd party plugins directories, e.g. RABBITMQ_3RD_PARTY_PLUGINS_DIRS.

Then set RABBITMQ_PLUGINS_DIR = RABBITMQ_3RD_PARTY_PLUGINS_DIRS;RABBITMQ_PLUGINS_DIR for all internal usages.

This approach will solve the RabbitMQ with 3rd party plugins upgrade problem:

1. If 3rd party plugins are inside the RabbitMQ installation directory and RABBITMQ_PLUGINS_DIR is not set (default), RabbitMQ upgrade will fail to start service, because the 3rd party plugins were deleted and must be copied to the new RabbitMQ installation directory again.
2. If 3rd party plugins are outside the RabbitMQ installation directory (which is still not supported for Windows), RABBITMQ_PLUGINS_DIR must be updated to include new RabbitMQ installation directory before RabbitMQ installation, when the default RabbitMQ installation directory is still unknown and can be only guessed (Typically C:\Program Files\RabbitMQ..., but formally - unknown).

[michaelklishin]

@inikulshin just so you know your sarcasm is not appreciated.

RABBITMQ_PLUGINS_DIR supports a path separator for similar reasons. I don't see how your suggestion would be meaningfully different (or more suitable for Windows).

[inikulshin]

It is not only for Windows:

Suppose RABBITMQ_PLUGINS_DIR supports multiple directories and we set it to RABBITMQ_PLUGINS_DIR=C:\plugins;C:\Program Files\RabbitMQ Server\rabbitmq_server-3.6.10\plugins

And now we want to write a script for RabbitMQ upgrade to version X.Y.Z, using default installation directory, which is typically known, but not guaranteed.

Please, advice the order of actions in a script, without service failure with "nodedown".

P.S. Well, initial path C:\Program Files\RabbitMQ Server\rabbitmq_server-3.6.10\plugins is also "guessed", so the problem is not only in upgrade.

P.P.S. Actually I can parse this path from Computer\HKLM\SOFTWARE\Ericsson\Erlang\ErlSrv\1.1\RabbitMQ\Args: -rabbit plugins_dir ... but only after installation.

[michaelklishin]

@inikulshin if you don't know installation paths you may want to revisit your installation procedure. RabbitMQ node data directory and installation location can be customised.

https://github.com/rabbitmq/rabbitmq-server/pull/1016 was contributed to make shipping and upgrading 3rd party plugins easier, in particular for Debian and RPM packages by allowing 3rd party plugins to be in a predefined directory that is known. #1016 did not cover Windows but I see no reason why the same approach wouldn't work there.

Our team does not use issues for discussions. Please use the mailing list for that.

[michaelklishin]

I updated issue description to explain what's missing. Without a default deploying 3rd party plugins is painful for scripts that are no aware of the target version.

[lukebakken]

@michaelklishin what about RABBITMQ_ADDITIONAL_PLUGINS_PATH which would be a list of additional directories used to discover plugins. We do have other environment variables in the form *_ADDITIONAL_* so this could be considered "familiar".

Using _PATH rather than _DIR or _DIRS might make it more self-evident that it's a list of directories.

[michaelklishin]

I'm OK with doing that but the root cause here is the lack of a fixed, well known location for Windows.

[lukebakken]

That would be up to the user to decide, right?

I think the "official" recommendation for recent Windows versions would be C:\ProgramData\RabbitMQ\X.Y.Z\plugins for plugins that ship with RMQ and something like C:\ProgramData\RabbitMQ\plugins as a default place to look for 3rd-party plugins.

[michaelklishin]

Paths that include versions can be impossible for installers to compute. C:\ProgramData\RabbitMQ\plugins sounds OK if C:\ProgramData\ is an equivalent of /usr/local/lib on modern Windows versions.

[lukebakken]

Paths that include versions can be impossible for installers to compute

Whose installers? Third-party? They would use the "generic" directory C:\ProgramData\RabbitMQ\plugins. We still need a version-specific directory to prevent mixing shipping plugins from third-party ones so that un-installations don't delete 3rd-party plugins. Unless I'm missing something here :smile:

[michaelklishin]

There's already a version-specific one. This issue is only about adding a version-agnostic one.

[lukebakken]

I see. Now I'm curious where the plugin archives are expanded to ...