Dealing with incompatible mapping changes

[clintongormley]

We're in the process of removing some mapping functionality such as the _analyzer field (#9279), the _boost field (#8875), and the type-level analyzer settings (#8874).

In all these cases, we need to:

• inform the user that the old settings no longer works
• allow the user to continue using their data without reindexing, even though the old settings no longer have any effect

I think we should throw an exception by default, so that the user knows that there is a problem (rather than just silently changing behaviour), but we need to provide some way for the user to say "go ahead and use this index anyway".

Possibilities:

• apply a setting to the closed index to say "ignore the old setting", then allow opening the index
• perhaps just upgrade the mapping to remove the setting if the user manually opens the index (or add a "force" flag to the open API?)
• add functionality to the upgrade API to make the required mapping changes

any preferences or better ideas?

[jpountz]

Option 2 sounds good. The open index API could return the list of reasons why the index cannot be open (if any), and the force flag (or maybe a better name that would make clear that we are making changes to the index that cannot be undone) would open this index and ignore the old removed settings.

[colings86]

@clintongormley what do you think of @jpountz recommendation?

[clintongormley]

This has been dealt with on a case-by-case basis. Where we can upgrade settings, we do. Where we can't, we refuse to open the index. The migration plugin (#10214) allows users to identify problems indices before upgrading.