Provide a declarative way to manage plugins #70219
Assignees
Labels
:Core/Infra/Plugins
Plugin API and infrastructure
:Delivery/Packaging
RPM and deb packaging, tar and zip archives, shell and batch scripts
Team:Core/Infra
Meta label for core/infra team
Team:Delivery
Meta label for Delivery team
Comments
jasontedor
added
:Delivery/Packaging
elasticmachine
added
Team:Delivery
|
Pinging @elastic/es-delivery (Team:Delivery) |
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
|
We discussed a narrower way of achieving a similar end a bit ago in #61385 |
pugnascotia
added a commit
that referenced
this issue
Jul 28, 2021
Part of #70219. Split the install and remove plugin CLI commands into `Command` and `Action` classes, so that the main implementations can be reused in a later PR to create a `Sync` command.
pugnascotia
added a commit
that referenced
this issue
Jul 28, 2021
Part of #70219. Split the install and remove plugin CLI commands into `Command` and `Action` classes, so that the main implementations can be reused in a later PR to create a `Sync` command.
ywangd
pushed a commit
to ywangd/elasticsearch
that referenced
this issue
Jul 30, 2021
Part of elastic#70219. Split the install and remove plugin CLI commands into `Command` and `Action` classes, so that the main implementations can be reused in a later PR to create a `Sync` command.
pugnascotia
added a commit
to pugnascotia/elasticsearch
that referenced
this issue
Sep 28, 2021
Part of elastic#70219. In order to share the plugin install and remove actions with the Elasticsearch server, introduce a `PluginLogger` interface for the action classes to use instead of referencing `Terminal` directly.
pugnascotia
added a commit
to pugnascotia/elasticsearch
that referenced
this issue
Sep 30, 2021
Part of elastic#70219. In order to share the plugin install and remove actions with the Elasticsearch server, introduce a `PluginLogger` interface for the action classes to use instead of referencing `Terminal` directly.
pugnascotia
added a commit
that referenced
this issue
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.
pugnascotia
added a commit
to pugnascotia/elasticsearch
that referenced
this issue
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.
elasticsearchmachine
pushed a commit
that referenced
this issue
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.
pugnascotia
added a commit
that referenced
this issue
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Today management of plugins is done through a CLI tool that exposes
list,install, andremovecommands. End-users and orchestration systems must use these tools to manage the installation and removal of the appropriate plugins, including addressing our existing limitation that plugins are version-locked to a patch version of Elasticsearch. These requirements lead to a poor end-user experience, and complexity for orchestration systems.A simpler approach would be to enable plugins to be managed through a configuration.
For example, one way to do this would be via a declarative list. You could imagine a user-managed
elasticsearch-plugins.ymlthat lists the plugin that an end-user or orchestration system wants installed (this list could be our usual syntax today, a name of an official plugin, Maven coördinates, or a URL). In the Elasticsearch startup script, we could diff this list with the installed plugins, remove those that are not listed, and install those that are. This declarative configuration file could include options likebatch: trueto install without inspecting permissions, and various other options for controlling how plugins are installed (for example, perhaps we need to enable setting proxy system properties here).There are, of course, several details to work out (e.g., how do we efficiently obtain the name of non-official plugins for comparing to the list of installed plugins) but the purpose of this issue is to encourage us to investigate ways to install plugins declaratively.
The text was updated successfully, but these errors were encountered: