Updating TransportRolloverAction.checkBlock so that non-write-index blocks do not prevent data stream rollover#122905
Conversation
…locks do not prevent data stream rollover
|
Hi @masseyke, I've created a changelog YAML for you. |
…ticsearch into rollover-action-checkBlock
|
Pinging @elastic/es-data-management (Team:Data Management) |
…ticsearch into rollover-action-checkBlock
| ResolvedExpression resolvedRolloverTarget = SelectorResolver.parseExpression(request.getRolloverTarget(), request.indicesOptions()); | ||
| final IndexAbstraction indexAbstraction = state.metadata().getIndicesLookup().get(resolvedRolloverTarget.resource()); | ||
| final String[] indicesToCheck; | ||
| if (indexAbstraction.getType().equals(IndexAbstraction.Type.DATA_STREAM)) { |
There was a problem hiding this comment.
Do we support rollover on data stream aliases? If so, would this get tripped up on one?
There was a problem hiding this comment.
That's a good question! But fortunately this code is in masterOperation: https://github.com/elastic/elasticsearch/blob/main/server/src/main/java/org/elasticsearch/action/admin/indices/rollover/TransportRolloverAction.java#L238-L243:
if (rolloverTargetAbstraction.getType() == IndexAbstraction.Type.ALIAS && rolloverTargetAbstraction.isDataStreamRelated()) {
listener.onFailure(
new IllegalStateException("Aliases to data streams cannot be rolled over. Please rollover the data stream itself.")
);
return;
}
| assertNotNull(transportRolloverAction.checkBlock(rolloverRequest, clusterState)); | ||
| } | ||
| { | ||
| // Make sure checkBlock returns an exception when failure store non-write indices has a block |
There was a problem hiding this comment.
| // Make sure checkBlock returns an exception when failure store non-write indices has a block | |
| // Make sure checkBlock returns null when failure store non-write indices has a block |
There was a problem hiding this comment.
Oops good catch. Also the verb is wrong in that comment. Fixing both.
💔 Backport failed
You can use sqren/backport to manually backport by running |
…locks do not prevent data stream rollover (elastic#122905)
…locks do not prevent data stream rollover (elastic#122905)
…locks do not prevent data stream rollover (elastic#122905)
…locks do not prevent data stream rollover (elastic#122905)
Since elastic#122905 we were throwing NPEs (i.e. 5xxs) when a rollover request has an unknown/non-existent target. This PR restores that to it's original behavior (which is to return a 400 - illegal argument exception). Additionally, to avoid this from happening again, we add a YAML test that asserts the correct exception behavior.
Since elastic#122905 we were throwing NPEs (i.e. 5xxs) when a rollover request has an unknown/non-existent target. This PR restores that to it's original behavior (which is to return a 400 - illegal argument exception). Additionally, to avoid this from happening again, we add a YAML test that asserts the correct exception behavior.
Since #122905 we were throwing NPEs (i.e. 5xxs) when a rollover request has an unknown/non-existent target. Before that, we returned a 400 - illegal argument exception. We now return a 404 which matches "missing target" better. Additionally, to avoid this from happening again, we add a YAML test that asserts the correct exception behavior.
Since elastic#122905 we were throwing NPEs (i.e. 5xxs) when a rollover request has an unknown/non-existent target. Before that, we returned a 400 - illegal argument exception. We now return a 404 which matches "missing target" better. Additionally, to avoid this from happening again, we add a YAML test that asserts the correct exception behavior. (cherry picked from commit fdd4537) # Conflicts: # server/src/main/java/org/elasticsearch/action/admin/indices/rollover/MetadataRolloverService.java
Since elastic#122905 we were throwing NPEs (i.e. 5xxs) when a rollover request has an unknown/non-existent target. Before that, we returned a 400 - illegal argument exception. We now return a 404 which matches "missing target" better. Additionally, to avoid this from happening again, we add a YAML test that asserts the correct exception behavior. (cherry picked from commit fdd4537) # Conflicts: # server/src/main/java/org/elasticsearch/action/admin/indices/rollover/MetadataRolloverService.java
) Since #122905 we were throwing NPEs (i.e. 5xxs) when a rollover request has an unknown/non-existent target. Before that, we returned a 400 - illegal argument exception. We now return a 404 which matches "missing target" better. Additionally, to avoid this from happening again, we add a YAML test that asserts the correct exception behavior. (cherry picked from commit fdd4537) # Conflicts: # server/src/main/java/org/elasticsearch/action/admin/indices/rollover/MetadataRolloverService.java
) Since #122905 we were throwing NPEs (i.e. 5xxs) when a rollover request has an unknown/non-existent target. Before that, we returned a 400 - illegal argument exception. We now return a 404 which matches "missing target" better. Additionally, to avoid this from happening again, we add a YAML test that asserts the correct exception behavior. (cherry picked from commit fdd4537) # Conflicts: # server/src/main/java/org/elasticsearch/action/admin/indices/rollover/MetadataRolloverService.java
) Since #122905 we were throwing NPEs (i.e. 5xxs) when a rollover request has an unknown/non-existent target. Before that, we returned a 400 - illegal argument exception. We now return a 404 which matches "missing target" better. Additionally, to avoid this from happening again, we add a YAML test that asserts the correct exception behavior. (cherry picked from commit fdd4537) # Conflicts: # server/src/main/java/org/elasticsearch/action/admin/indices/rollover/MetadataRolloverService.java
Since elastic#122905 we were throwing NPEs (i.e. 5xxs) when a rollover request has an unknown/non-existent target. Before that, we returned a 400 - illegal argument exception. We now return a 404 which matches "missing target" better. Additionally, to avoid this from happening again, we add a YAML test that asserts the correct exception behavior.
Right now, TransportRolloverAction's checkBlock returns an exception if any backing index has a block. If a user puts a block on some old index, the data stream cannot rollover, even though rollover only impacts the write index (and the to-be-created write index). This changes TransportRolloverAction.checkBlock so that rollover doesn't fail if non-write-indices have a block.