-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handling of _all field in indices migrated from 5.x to 6.0 #25068
Comments
This is a bug. 5.x indices should keep working in the same way as before when the cluster is upgraded to 6.x. This means that I'd also be OK with upgrading the 5.x mappings to make |
@clintongormley @dakrone Can you help fill out the table? Given the 5.x scenario on the left, what should happen when they upgrade, and should we raise a deprecation issue in the migration tool?
|
@archanid i've updated the table |
thanks @clintongormley Just to clarify, what I meant by "improperly configured", and I should have been more clear, is |
When we disabled `_all` by default for indices created in 6.0, we missed adding a layer that would handle the situation where `_all` was not enabled in 5.x and then the cluster was updated to 6.0, this means that when the cluster was updated the `_all` field would be disabled for 5.x indices and field values would not be added to the `_all` field. This adds a compatibility layer for 5.x indices where we treat the default enabled value for the `_all` field to be `true` if unset on 5.x indices. Resolves elastic#25068
🎉 |
In #22144 we disabled
_all
field by default, which means that that unless_all
was explicitly enabled in a 5.x mapping, it will be disabled in 6.0 after upgrade. In other words, 5.x indices with_all
explicitly enabled will continue to work in 6.0 as before, while indices with_all
not explicitly enabled will lose_all
fields and will start to use our fallback mechanism for all fields queries.After discussions with @archanid and @dakrone we couldn't come to a clear conclusion on how this situation should be handled. We see at least 2 options here.
It can be fixed by updating all existing 5.x mappings to have
_all
explicitly enabled when the first 6.0 node shows up in the cluster.Alternatively we can just update our documentation that doesn't seem to explicitly say what happens to the existing mappings.
The text was updated successfully, but these errors were encountered: