Shrink API attempts to apply mapping from index templates.

[A-Hall]

Elasticsearch version: 5.3

Plugins installed: Cerebro, X-Pack

JVM version (java -version): 1.8.0_66

OS version (uname -a if on a Unix-like system): RHEL 7.3

Description of the problem including expected versus actual behavior: When trying to call shrink API and the destination index matches a template that provides mappings they get an error:

{"error":{"root_cause":[{"type":"remote_transport_exception","reason":"[xxx-master][x.x.x.x:9300][indices:admin/shrink]"}],"type":"illegal_argument_exception","reason":"mappings are not allowed when shrinking indices, all mappings are copied from the source index"},"status":400}

It would be nice if the shrink API bypassed checking for index templates that match the destination index. The error is misleading too since no mappings were provided by the user.

Steps to reproduce:

1. Create index template for FooIndex* that includes a mapping.
2. Create index that matches index pattern FooIndex*
3. Call Shrink API for index created in step 2, making destination index also match the pattern FooIndex*.

[fred84]

@clintongormley I want to take this issue.

[clintongormley]

@fred84 go for it

[fred84]

@clintongormley Hello. I have fixed this this bug, but need advice on further implementation.

1. There are also aliases and customs applied to index from template. Should we also ignore them when shrinking index?
2. Anonymous subclass of AckedClusterStateUpdateTask in MetaDataCreateIndexService contains lots of logic inside. I think we may convert it to inner class so it will be possible to unit-test this class. Here is code demonstrating this idea: https://github.com/fred84/elasticsearch/pull/1/files . Am I going in right direction?

[clintongormley]

Hi @fred84

Thanks for taking this on! I think that the shrunk index should ignore anything from templates and instead take its mappings, aliases, and settings from the original index, plus any new settings and aliases passed in with the shrink request.

As far as the direction you're going, I'll defer to @s1monw on that

[jasontedor]

Closed by #25380