Introduce declarative plugin management #77544
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
Also fix how the cloud-ess image depends on the cloud image.
pugnascotia
added
>feature
:Core/Infra/Plugins
|
@mark-vieira I've added support for testing plugin installation on all Docker flavours, using the I also tried to re-enable |
mark-vieira
approved these changes
Nov 11, 2021
|
I talked to Cloud Delivery and it doesn't look like the wrapper script is being used, so we're good to merge. |
|
Oh, and I will add docs but I think that'll require some collaboration with the Docs folks, so I'll do that separately. |
pugnascotia
added a commit
to pugnascotia/elasticsearch
that referenced
this pull request
Nov 15, 2021
Closes elastic#70219. Introduce a declarative way for the Elasticsearch server to manage plugins, which reads the `elasticsearch-plugins.yml` file and works which out plugins need to be added and / or removed to match the configuration. Also make it possible to configure a proxy in the config file, instead of through the environment. Most of the work of adding and removing is still done in the `InstallPluginAction` and `RemovePluginAction` classes, so the behaviour should be the same as with the `install` and `remove` commands. However, these commands will now abort if the above config file exists. The intent is to make it harder for the configuration to drift. This new method only applies to `docker` distribution types at the moment. Since this syncing mechanism declarative, rather than imperative, the Cloud-specific plugin wrapper script is no longer required. Instead, an environment variable informs `InstallPluginAction` to install plugins from an archive directory instead of downloading them, where possible.
This was referenced Nov 15, 2021
elasticsearchmachine
pushed a commit
that referenced
this pull request
Nov 15, 2021
Closes #70219. Introduce a declarative way for the Elasticsearch server to manage plugins, which reads the `elasticsearch-plugins.yml` file and works which out plugins need to be added and / or removed to match the configuration. Also make it possible to configure a proxy in the config file, instead of through the environment. Most of the work of adding and removing is still done in the `InstallPluginAction` and `RemovePluginAction` classes, so the behaviour should be the same as with the `install` and `remove` commands. However, these commands will now abort if the above config file exists. The intent is to make it harder for the configuration to drift. This new method only applies to `docker` distribution types at the moment. Since this syncing mechanism declarative, rather than imperative, the Cloud-specific plugin wrapper script is no longer required. Instead, an environment variable informs `InstallPluginAction` to install plugins from an archive directory instead of downloading them, where possible.
|
I think we missed backporting this to 8.0 although we did to 7.16. |
pugnascotia
added a commit
that referenced
this pull request
Nov 16, 2021
Closes #70219. Introduce a declarative way for the Elasticsearch server to manage plugins, which reads the `elasticsearch-plugins.yml` file and works which out plugins need to be added and / or removed to match the configuration. Also make it possible to configure a proxy in the config file, instead of through the environment. Most of the work of adding and removing is still done in the `InstallPluginAction` and `RemovePluginAction` classes, so the behaviour should be the same as with the `install` and `remove` commands. However, these commands will now abort if the above config file exists. The intent is to make it harder for the configuration to drift. This new method only applies to `docker` distribution types at the moment. Since this syncing mechanism declarative, rather than imperative, the Cloud-specific plugin wrapper script is no longer required. Instead, an environment variable informs `InstallPluginAction` to install plugins from an archive directory instead of downloading them, where possible.
|
Sorry - backported to |
pugnascotia
added a commit
to pugnascotia/elasticsearch
that referenced
this pull request
Nov 16, 2021
pugnascotia
added a commit
that referenced
this pull request
Nov 17, 2021
pugnascotia
added a commit
that referenced
this pull request
Nov 17, 2021
pugnascotia
added a commit
that referenced
this pull request
Nov 17, 2021
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.
Closes #70219.
Introduce a declarative way for the Elasticsearch server to manage plugins, which reads the
elasticsearch-plugins.ymlfile and works which plugins need to be added and / or removed to match the configuration. Also make it possible to configure a proxy in the config file, instead of through the environment.Most of the work of adding and removing is still done in the
InstallPluginActionandRemovePluginActionclasses, so the behaviour should be the same as with theinstallandremovecommands. However, these commands will now abort if the above config file exists. The intent is to make it harder for the configuration to drift.This new method only applies to
dockerdistribution types at the moment.Since this syncing mechanism declarative, rather than imperative, the Cloud-specific plugin wrapper script is no longer required. Instead, an environment variable informs
InstallPluginActionto install plugins from an archive directory instead of downloading them, where possible.