- Notifications
You must be signed in to change notification settings - Fork 25.7k
Remove any references to org.elasticsearch.core.RestApiVersion#V_7 #118103
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
Remove any references to org.elasticsearch.core.RestApiVersion#V_7 #118103
Conversation
f9b5491 to eea5e77 Compare server/src/main/java/org/elasticsearch/action/ingest/SimulatePipelineRequest.java Show resolved Hide resolved
server/src/main/java/org/elasticsearch/ingest/IngestDocument.java Outdated Show resolved Hide resolved
| Hi @JVerwolf, I've created a changelog YAML for you. Note that since this PR is labelled |
| Hi @JVerwolf, I've updated the changelog YAML for you. |
| Hi @JVerwolf, I've updated the changelog YAML for you. Note that since this PR is labelled |
…ent/remove-rest-api-v-7-references
…ent/remove-rest-api-v-7-references
| @UpdateForV10(owner = UpdateForV10.Owner.DATA_MANAGEMENT) // Replace with just RestApiVersion.values() when V8 no longer exists | ||
| public static final List<RestApiVersion> REST_API_VERSIONS_POST_V8 = Stream.of(RestApiVersion.values()) | ||
| .filter(v -> v.compareTo(RestApiVersion.V_8) > 0) | ||
| .filter(v -> v.major > RestApiVersion.V_8.major) |
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.
For the Data Management folks, Can you double check this? Specifically, that values > V_8 is the desired behaviour?
I think this was a bug. After removing V_7, this would return an empty list, causing tests to fail. This was previously returning a list containing only V_7 (as the ordinal for V_7 was greater than the ordinal for V_8). I don't think that behaviour was intended.
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.
@PeteGillinElastic can you confirm 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.
Yeah, this is my bad. Thanks for catching it. The intention was to include values later than V_8 — but, of course, compareTo on enums compares by the order the values are defined in the enum, which for RestApiVersion is "backwards", so it was actually getting earlier than V_8 (and even that behaviour was fragile as it depends on the declaration order which shouldn't be part of the contract).[*]
Your change looks good. Alternatively, I wonder whether v.matches(RestApiVersion.onOrAfter(RestApiVersion.V_9)) might be even more explicit? Or v != RestApiVersion.V_8, which is equivalent once V_7 goes away?
Aside: It feels like we should discourage the use of compareTo on RestApiVersion, since its behaviour is so counter-intuitive. I was going to suggest that we could override it with an implementation which just delegates to super and @Deprecate it — but it's declared as final on Enum, so that doesn't work. My personal opinion is that it was probably a mistake for Enum to implement Comparable in the first place, but we make use of it way too many times to consider banning it via static analysis.
[*] If, like me, you're wondering why the test passed with this bug: It's because in the code under test we effectively just test for != RestApiVersion.V_8, which seems safe since we knew that V_7 was going to go away before V9 shipped. We've been writing BWC logic this way to ensure that it explicitly references the older version, V_8 in this case, to guarantee that we remember to remove it when V_8 goes away.
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.
Thanks @PeteGillinElastic , I updated this to use v.matches(RestApiVersion.onOrAfter(RestApiVersion.V_9)) as per your suggestion.
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 don't see that change pushed here yet... But LGTM anyway.
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'll leave @dakrone to give the overall approval for the DM stuff when he's ready.
| // serialized to older nodes where the transport action was a MasterNodeReadAction. | ||
| // TODO: Make this a simple request in a future version where there is no possibility | ||
| // of this request being serialized to another node. | ||
| @UpdateForV9(owner = UpdateForV9.Owner.MACHINE_LEARNING) |
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.
ML Folks: As per the comment above, can this now be updated for V9? If so I'll leave the annotation.
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.
👍 thanks for creating the annotation
| Pinging @elastic/es-core-infra (Team:Core/Infra) |
ldematte left a comment
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.
Core/Infra part looks good! Good comments/questions for ML and Data-Management; please follow up with them to ensure the behaviour is still correct.
| Pinging @elastic/ml-core (Team:ML) |
| Pinging @elastic/es-data-management (Team:Data Management) |
dakrone left a comment
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 some comments from the Data Management side
| if (restApiVersion != RestApiVersion.V_8 && dataMap.containsKey(Metadata.TYPE.getFieldName())) { | ||
| deprecationLogger.compatibleCritical( | ||
| "simulate_pipeline_with_types", | ||
| "[types removal] specifying _type in pipeline simulation requests is deprecated" | ||
| ); | ||
| } |
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.
This was intentional, as we need to deprecate this in 9.0 as well. See #116259 for the background. I believe we still need this code.
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.
Should the logic here be restApiVersion.major < RestApiVersion.V_9.major && ... then?
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.
@dakrone I changed this to:
if (restApiVersion != null && restApiVersion.major < RestApiVersion.V_9.major && dataMap.containsKey(Metadata.TYPE.getFieldName())) { The null check was required to prevent serverless tests from failing (see gradle build scan for details)
Do we even need a version check here, or is the dataMap.containsKey( enough?
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.
I think that logic is slightly different, because we want to deprecate if the restApiVersion is null still, and we don't want deprecations for the v8 API version, but we do want it for all later versions.
So it should be:
if (dataMap.containsKey(Metadata.TYPE.getFieldName()) && (restApiVersion == null || restApiVersion.major > RestApiVersion.V_8.major)) {"If the map contains the _type key and either the API version is missing or greater than v8 — issue the deprecation warning"
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.
Makes sense, thanks @dakrone. Fixed.
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.
Wait, are you sure we don't want to log this as critically deprecated in V_8? (We are deprecating in V_8, but not removing, right?)
This fails the test I updated to use V_8 from V_7.
This should be:
if( dataMap.containsKey(Metadata.TYPE.getFieldName()) && (restApiVersion == null || restApiVersion.major < RestApiVersion.V_9.major)) {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.
We're deprecating in 8.18, and not removing until 10.0. Previously we had:
v7 — not supported
v8 — should be deprecated
v9 — should be deprecated
So I think you're right, instead it should just be:
if (dataMap.containsKey(Metadata.TYPE.getFieldName())) {With an UpdateForV10 that says "drop support for this in 10.0 unless someone is using v9 API compatibility"
Does that sound right to you?
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.
That sounds right to me, thanks!
server/src/main/java/org/elasticsearch/ingest/IngestDocument.java Outdated Show resolved Hide resolved
| @UpdateForV10(owner = UpdateForV10.Owner.DATA_MANAGEMENT) // Replace with just RestApiVersion.values() when V8 no longer exists | ||
| public static final List<RestApiVersion> REST_API_VERSIONS_POST_V8 = Stream.of(RestApiVersion.values()) | ||
| .filter(v -> v.compareTo(RestApiVersion.V_8) > 0) | ||
| .filter(v -> v.major > RestApiVersion.V_8.major) |
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.
@PeteGillinElastic can you confirm here?
| assertThat(e3.getMessage(), containsString("required property is missing")); | ||
| } | ||
| | ||
| public void testIngestPipelineWithDocumentsWithType() throws Exception { |
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.
We'll still need this test as (unfortunately) this is still available in 9.0 but deprecated.
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.
Roger. Given that this test can no longer reference V_7, I'll update it to V_8 and then adjust the logic in server/src/main/java/org/elasticsearch/action/ingest/SimulatePipelineRequest.java as described in this comment. WDYT?
…ent/remove-rest-api-v-7-references
…om:JVerwolf/elasticsearch into enhancement/remove-rest-api-v-7-references
…ent/remove-rest-api-v-7-references
davidkyle left a comment
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.
ML changes LGTM. Thanks for the clean up
| // serialized to older nodes where the transport action was a MasterNodeReadAction. | ||
| // TODO: Make this a simple request in a future version where there is no possibility | ||
| // of this request being serialized to another node. | ||
| @UpdateForV9(owner = UpdateForV9.Owner.MACHINE_LEARNING) |
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.
👍 thanks for creating the annotation
…om:JVerwolf/elasticsearch into enhancement/remove-rest-api-v-7-references
dakrone left a comment
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.
LGTM on the Data Management side
…om:JVerwolf/elasticsearch into enhancement/remove-rest-api-v-7-references
| @JVerwolf is this PR relevant to the serverless changelog? [FYI this question is based on 9.0 breaking changes] |
| @leemthompo Thanks for checking. These are internal to ES and don't represent changes that need to be mentioned to users. |
This PR removes any references to org.elasticsearch.core.RestApiVersion#V_7.
To save time, I made the requisite deprecations for ML and Data-Management code that were necessary to remove the V_7 code owned by Core-Infra. After approval from Core-Infra, I will then seek review from both of the other teams prior to merging.