-
Notifications
You must be signed in to change notification settings - Fork 24.7k
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
Index name resolver should not match '.*' indices unless pattern starts with '.' #29605
Comments
Pinging @elastic/es-core-infra |
This is going to affect also whoever creates indices starting with |
We spoke about this in fixit friday and we came up with an idea. I tried to make indices hidden in the past and it had some issues and tired to do more. I think I can take another look at it with these requirements:
@javanna @clintongormley WDYT |
Sounds good to me. I presume we'd have an expand indices option which would allow us to resolve wildcards to hidden indices as well? (Otherwise we'd have no way of figuring out if such indices exist other than trying each one by name).
Why would we need to mark aliases as hidden? Surely the fact that the alias resolves to hidden indices would be sufficient? |
This option would be very useful for ML, as ML can have many internal indices. Even if we somehow managed to get away without it for production, it would make life hard for developers if we cannot search |
@droberts195 I think this is already handled in the issue description. Your example starts with |
This will likely be superseded by whatever is decided in #38678. |
Hidden aliases have been implemented in #52547 |
Internal indices should behave as non-existent for the user unless explicitly requested. Basically, like linux, we change the index name resolver to always exclude indices starting with '.' unless the index expression explicitly starts with a '.'. This would avoid expressions matching internal indices, which most of the time would lead to unwanted surprises.
The text was updated successfully, but these errors were encountered: