Make plugin install idempotent

[anyasabo]

It would be useful if bin/elasticsearch-plugin install --batch could be called repeatedly. As it is, the first call will succeed and subsequent calls will fail. This comes up not infrequently in Kubernetes environments, where we may install plugins as an init container (which runs before the Elasticsearch container), but some maintenance operations may cause it to run again and error out. If it could detect that it has already run successfully and exit gracefully it would be helpful.

There are workarounds including:

• test for plugin existence before installing
• create a new docker image with the plugin already installed, so never use an init container

But both add extra complexity on the user side.

Here's an ECK issue discussing this for reference:
elastic/cloud-on-k8s#3530

We also have similar issues with initializing the keystore, but we can discuss that in a separate issue.

[elasticmachine]

Pinging @elastic/es-core-infra (:Core/Infra/Plugins)

[pugnascotia]

We discussed this issue in the Core/Infra sync. @anyasabo would it work for you to pass an extra flag, e.g. --ignore-existing, that would stop the install process exiting with a failure if a plugin was already present? There's no infrastructure in place right now for comparing the currently-installed plugin with the to-be-installed plugin, so simply accepting the already-installed plugin would be simplest.

[anyasabo]

👍 that makes sense to me

[williamrandolph]

This issue looks like something that the core-infra team should plan to work on, so I'm going to remove the needs:triage label and leave it as is.

[irizzant]

I have applied the following workaround:

command: [
            'sh',
            '-c',
            'bin/elasticsearch-plugin install --batch repository-s3 || true',
          ],

[mark-vieira]

We might want to consider this a duplicate of #70219. The use case described in that issue would solve this problem as well.

[B-Souty]

Has there been any progress on this issue? We just had this issue in production using ECK where a master was in a crash loop due to a plugin already installed. I really like the solution proposed in #70219

[epicvinny]

Has there been any progress on this issue? We just had this issue in production using ECK where a master was in a crash loop due to a plugin already installed. I really like the solution proposed in #70219

+1

[rjernst]

Closing in favor of #70219