Skip to content

Conversation

@JVerwolf
Copy link
Contributor

@JVerwolf JVerwolf commented Dec 5, 2024

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.

@JVerwolf JVerwolf force-pushed the enhancement/remove-rest-api-v-7-references branch from f9b5491 to eea5e77 Compare December 5, 2024 21:25
@JVerwolf JVerwolf added >deprecation :Core/Infra/Core Core issues without another label labels Dec 5, 2024
@elasticsearchmachine
Copy link
Collaborator

Hi @JVerwolf, I've created a changelog YAML for you. Note that since this PR is labelled >deprecation, you need to update the changelog YAML to fill out the extended information sections.

@JVerwolf JVerwolf requested review from a team and removed request for a team December 5, 2024 21:41
@elasticsearchmachine
Copy link
Collaborator

Hi @JVerwolf, I've updated the changelog YAML for you.

@elasticsearchmachine
Copy link
Collaborator

Hi @JVerwolf, I've updated the changelog YAML for you. Note that since this PR is labelled >breaking, you need to update the changelog YAML to fill out the extended information sections.

@JVerwolf JVerwolf changed the title [WIP] Remove any references to org.elasticsearch.core.RestApiVersion#V_7 Remove any references to org.elasticsearch.core.RestApiVersion#V_7 Dec 6, 2024
@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)
Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Member

@PeteGillinElastic PeteGillinElastic Dec 11, 2024

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

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)
Copy link
Contributor Author

@JVerwolf JVerwolf Dec 6, 2024

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.

Copy link
Member

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

@JVerwolf JVerwolf marked this pull request as ready for review December 6, 2024 19:25
@elasticsearchmachine elasticsearchmachine added the Team:Core/Infra Meta label for core/infra team label Dec 6, 2024
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (Team:Core/Infra)

Copy link
Contributor

@ldematte ldematte left a 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.

@JVerwolf JVerwolf added :ml Machine learning :Data Management/Data streams Data streams and their lifecycles labels Dec 9, 2024
@elasticsearchmachine elasticsearchmachine added Team:Data Management Meta label for data/management team Team:ML Meta label for the ML team labels Dec 9, 2024
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/ml-core (Team:ML)

@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-data-management (Team:Data Management)

Copy link
Member

@dakrone dakrone left a 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

Comment on lines 180 to 185
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"
);
}
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

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?

Copy link
Member

@dakrone dakrone Dec 11, 2024

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"

Copy link
Contributor Author

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.

Copy link
Contributor Author

@JVerwolf JVerwolf Dec 11, 2024

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)) {
Copy link
Member

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?

Copy link
Contributor Author

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!

@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)
Copy link
Member

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 {
Copy link
Member

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.

Copy link
Contributor Author

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?

@JVerwolf JVerwolf requested a review from dakrone December 10, 2024 19:04
Copy link
Member

@davidkyle davidkyle left a 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)
Copy link
Member

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

Copy link
Member

@dakrone dakrone left a 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

@JVerwolf JVerwolf merged commit a560782 into elastic:main Dec 12, 2024
16 checks passed
@leemthompo
Copy link
Contributor

@JVerwolf is this PR relevant to the serverless changelog? [FYI this question is based on 9.0 breaking changes]

@JVerwolf
Copy link
Contributor Author

@leemthompo Thanks for checking. These are internal to ES and don't represent changes that need to be mentioned to users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>breaking :Core/Infra/Core Core issues without another label :Data Management/Data streams Data streams and their lifecycles :ml Machine learning Team:Core/Infra Meta label for core/infra team Team:Data Management Meta label for data/management team Team:ML Meta label for the ML team v9.0.0

7 participants