Implement auto upgrade for date fields

[pgomulka]

We noticed that there is an increased number of users struggling to migrate their mappings with date fields using old style joda patterns. Since 7.0 they need to upgrade to java.style patterns on these date fields.
This requires an index with a new mapping and a reindex.
Because this is a change in 7.0 I suppose I would need to have a logic like this in 6.8.

Should I implement this in javascript in kibana? Or should I aim to use the new infrastructure with painless #49764 (although I see an 8.0 label..)
The logic would be fairly simple and would perform automatic reindex only when a mapping migration can be 100% determined. Things like YYYY -> yyyy or yyyy -> uuuu and so on.
https://github.com/elastic/elasticsearch/blob/6.8/server/src/main/java/org/elasticsearch/common/joda/JodaDeprecationPatterns.java

Not sure if this should be under the reindex button in migration assistant or a logic invisible to a user?

Let me know what you think

relates issue in ES elastic/elasticsearch#45548

[elasticmachine]

Pinging @elastic/es-ui (Team:Elasticsearch UI)

[pgomulka]

we discussed this during elasticsearch-ui team meeting on 4th Feb
the conclusion is to make sure we will still have an opportunity to release this as a patch to 6.8 version. If this is agreed, then we will proceed with the implementation in kibana (possibly in the area of reindex service)
The alternative is to implement this as script which a user runs on its own and gets a list of commands that helps him create an index with a new mapping, reindex, repoint aliases

Also a points were raised, that reindex at the moment is used for stored objects in kibana, which are not massive (not comparable to some of the indices used by users). Reindex might end up very long and consume resources in kibana.

[alisonelizabeth]

Hi @pgomulka! Can you confirm if this is still relevant for the 7-8 upgrade? I believe when we last talked you mentioned there are too many combinations to cover to provide an "auto-upgrade" experience. Also, that this could only occur with indices created prior to 7.x.

[pgomulka]

hi @alisonelizabeth , yes I think it is too hard to implement and have a 100% correctness. also the indices created in 6.x are still respected in 7.x so I expect a big group of users won't be affected as their 6.x indices will get removed thanks to data retention.

[alisonelizabeth]

👍 thanks! I'm going to go ahead and close this for now then.