Get aliases for specific aliases returns all indices #27763
Comments
|
It's worth noting that this only affects the transport layer. The REST layer doesn't include the extra indices. The transport layer should probably be changed to return only indices that contain the alias when an alias name is specified. |
|
The transport client is exactly what this issue is being reported for. |
|
@jasontedor @dakrone In which release /version we can expect its fix.? |
|
The transport client is exactly what this issue is being reported for.
Yes I understand, I was only clarifying for the sake of other people
reading.
…On Dec 12, 2017 9:51 PM, "Jason Tedor" ***@***.***> wrote:
The transport client is exactly what this issue is being reported for.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#27763 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABKdIlsoCe_HDhcnutz3ym833dV9H3Nks5s_1fNgaJpZM4Q-Cu4>
.
|
Right now you can not have any expectation, no decision has been reached. |
|
+1 |
|
We discussed this in Fix-it-Friday and agree that this is a bug. Would you take care of this @dakrone. |
|
@antitech I want to be clear that while we agree this is bug, it is not a high priority bug so there is no expectation about the timeline for a fix. |
|
@jasontedor its ok. I'll apply any temporary fix for now . Just a request can you please attach this bug with aliases tag. |
|
+1 |
…iases api. If a get alias api call requests a specific alias pattern then indices not having any matching aliases should not be included in the response. Closes #27763
|
Reopening this issue, because a qa test failed in another project, in this case the aliases were being expanded (via AliasesRequest#aliases(...)) before arriving in the transport action. |
clintongormley
added
:Data Management/Indices APIs
|
@martijnvg Is it possible to resolve this issue? |
…iases api. If a get alias api call requests a specific alias pattern then indices not having any matching aliases should not be included in the response. This is a second attempt to fix this (first attempt was elastic#28294). The reason that the first attempt was reverted is because when xpack security is enabled then index expression (like * or _all) are resolved prior to when a request is processed in the get aliases transport action, then `MetaData#findAliases` can't know whether requested all where requested since it was already expanded in concrete alias names. This change replaces aliases(...) replaceAliases(...) method on AliasesRequests class and leave the aliases(...) method on subclasses. So there is a distinction between when xpack security replaces aliases and a user setting aliases via the transport or high level http client. Closes elastic#27763
…iases api. (#29538) If a get alias api call requests a specific alias pattern then indices not having any matching aliases should not be included in the response. This is a second attempt to fix this (first attempt was #28294). The reason that the first attempt was reverted is because when xpack security is enabled then index expression (like * or _all) are resolved prior to when a request is processed in the get aliases transport action, then `MetaData#findAliases` can't know whether requested all where requested since it was already expanded in concrete alias names. This change replaces aliases(...) replaceAliases(...) method on AliasesRequests class and leave the aliases(...) method on subclasses. So there is a distinction between when xpack security replaces aliases and a user setting aliases via the transport or high level http client. Closes #27763
…iases api. (#29538) If a get alias api call requests a specific alias pattern then indices not having any matching aliases should not be included in the response. This is a second attempt to fix this (first attempt was #28294). The reason that the first attempt was reverted is because when xpack security is enabled then index expression (like * or _all) are resolved prior to when a request is processed in the get aliases transport action, then `MetaData#findAliases` can't know whether requested all where requested since it was already expanded in concrete alias names. This change replaces aliases(...) replaceAliases(...) method on AliasesRequests class and leave the aliases(...) method on subclasses. So there is a distinction between when xpack security replaces aliases and a user setting aliases via the transport or high level http client. Closes #27763
I think the behavior specified in
IndexAliasesIT#testIndicesGetAliasesis wrong. Namely:This was a breaking change resulting from #25114, the specific change in behavior arising from a change to MetaData.
I am opening this personally considering it a bug but for discussion where we might decide to only document this behavior (not my preference, I think this behavior is weird and not intuitive).
Relates #27743
The text was updated successfully, but these errors were encountered: