Should we always install the main repository plugins?

[pugnascotia]

This issue is for discussing whether we should always install the following plugins in Elasticsearch:

• repository-s3
• repository-gcs
• repository-azure

Anyone running Elasticsearch one of the three main Cloud providers is likely using their object storage for backups, and other vendors also have S3-compatible system for performing backups in on-premise environments.

The upside of always bundling these plugins is that it relieves a piece of installation overhead, in particular making it easier to run the Docker image in a cloud environment.

The downside is that the distribution size will increase. There may be / are probably other downsides too.

We could:

1. Convert these plugins to modules and completely bake them in. This makes upgrading the code a non-issue, since it just gets upgraded along with Elasticsearch.
2. Keep them as plugins, which would give administrators the option to remove the plugins again if they wanted, but complicates the story around upgrades.

I would opt for (1) in order to avoid the complexity (and therefore bugs) associated with upgrades.

[elasticmachine]

Pinging @elastic/es-delivery (Team:Delivery)

[elasticmachine]

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

[mark-vieira]

Yeah, I'm apt to go with option (1) as well. Compressed these three plugins are 24MB so not a huge increase in distro size.

We should work to try and get this in 8.0+ soon as this is another breaking change given that these plugins will go away, so any scripts/etc folks have to install them will break. We want to give folks some heads up so getting this included and documented in rc-1 would be ideal.

[jasontedor]

We've dealt with migrating plugins to modules before: #36898 #36956 #36966

Effectively we made installing/removing these plugins no-ops until the next major.

[pugnascotia]

@jasontedor thanks for the pointer 👍

[bytebilly]

I'm +1 to include them by default. I did some telemetry analysis, and these plugins are used on ~10% of total deployments.

The suggested implementation path sounds like a breaking change only for people that really want to remove them.
Would it be a way to "disable" them once they will be modules?

[elasticmachine]

Pinging @elastic/es-distributed (Team:Distributed)

[jasontedor]

Would it be a way to "disable" them once they will be modules?

I don't think we need a way to disable them, and it's a simplification for us to not have a way to do so. We don't need ways to disable other repository types that are built-in to the system. These repository types being distributed as modules should be thought of as being no different than being built-in to the system. They don't consume any resources if they are not in use, so a user shouldn't have any concern in that regard, and when security is active, they require authentication/authorization to be able to create repositories that use them. Does that cover the reasons you have in mind for why a user would need to disable them, or are there other concerns that I'm overlooking?

[bytebilly]

Thanks Jason, this helps a lot and I don't have other specific concern that have not been addressed in your response.

If our target is 8.0, we are still introducing a breaking change with a very short notice.
However I'm supportive to that because of the high benefit and the low impact.

@qhoxie do you see any concern related to our Make it Minor effort?

[qhoxie]

No concerns on my end. We can proceed with option 1.

[jasontedor]

@bytebilly I think there's ways to avoid it being considered breaking until a deprecation period has elapsed, and we have some previous experience going through the process of transitioning plugins to modules: #81652 (comment).