-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
[Rest Api Compatibility] Deprecate the use of synced flush #75372
Conversation
synced flush is going to be replaced by flush. This commit deprecates the synced flush and is meant to be backported to 7.x relates elastic#50882 relates elastic#51816
Pinging @elastic/clients-team (Team:Clients) |
Pinging @elastic/es-core-infra (Team:Core/Infra) |
List<String> warningMsg = List.of("Synced flush was removed and a normal flush was performed instead. " + | ||
"This transition will be removed in a future version."); | ||
request.setOptions(RequestOptions.DEFAULT.toBuilder().setWarningsHandler(warnings -> warnings.equals(warningMsg) == false)); | ||
final String v7MediaType = XContentType.VND_JSON.toParsedMediaType() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure we would like to use synced flush here. Since it was deprecated in 7.x and is only available under rest compatibility in 8 I guess we should just use flush
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whole test is called testSyncedFlushTransition
and starts with assertTrue("bwc version is on 7.x", nodes.getBWCVersion().before(Version.V_8_0_0));
so I think it's right to still use synced-flush here. We could reasonably duplicate this test as one which just uses a regular flush and will continue to work once 7.x is no more.
Pinging @elastic/es-distributed (Team:Distributed) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a couple of comments, looks good otherwise.
@@ -683,7 +683,7 @@ public void testRecovery() throws Exception { | |||
flushRequest.addParameter("wait_if_ongoing", "true"); | |||
assertOK(client().performRequest(flushRequest)); | |||
if (randomBoolean()) { | |||
syncedFlush(index); | |||
flush(index, randomBoolean()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can just drop this, we already just force-flushed.
List<String> warningMsg = List.of("Synced flush was removed and a normal flush was performed instead. " + | ||
"This transition will be removed in a future version."); | ||
request.setOptions(RequestOptions.DEFAULT.toBuilder().setWarningsHandler(warnings -> warnings.equals(warningMsg) == false)); | ||
final String v7MediaType = XContentType.VND_JSON.toParsedMediaType() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whole test is called testSyncedFlushTransition
and starts with assertTrue("bwc version is on 7.x", nodes.getBWCVersion().before(Version.V_8_0_0));
so I think it's right to still use synced-flush here. We could reasonably duplicate this test as one which just uses a regular flush and will continue to work once 7.x is no more.
Map<String, Object> result = ObjectPath.createFromResponse(oldNodeClient.performRequest(request)).evaluate("_shards"); | ||
assertThat(result.get("total"), equalTo(totalShards)); | ||
assertThat(result.get("successful"), equalTo(totalShards)); | ||
assertThat(result.get("failed"), equalTo(0)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering, how is _flush
smarter then _flush/_synced
that it won't fail on old nodes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand. The _flush
API is ancient, it's fully supported on every version in scope here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggested removing a couple of remaining mentions of synced
in the new test, otherwise LGTM. No need for another review.
qa/mixed-cluster/src/test/java/org/elasticsearch/backwards/IndexingIT.java
Outdated
Show resolved
Hide resolved
qa/mixed-cluster/src/test/java/org/elasticsearch/backwards/IndexingIT.java
Outdated
Show resolved
Hide resolved
…exingIT.java Co-authored-by: David Turner <david.turner@elastic.co>
…exingIT.java Co-authored-by: David Turner <david.turner@elastic.co>
…5372) synced flush is going to be replaced by flush. This commit allows to synced_flush api only in v7 compatibility mode. Worth noting - sync_id is gone and won't be available in v7 responses from indices.stats relates removal pr elastic#50882 relates elastic#51816
synced flush is going to be replaced by flush. This commit allows to synced_flush api only in v7 compatibility mode.
Worth noting - sync_id is gone and won't be available in v7 responses from indices.stats
relates removal pr #50882
relates #51816
gradle check
?