Skip to content
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

Add deprecation warning to TransportHandshaker #123188

Merged

Conversation

JVerwolf
Copy link
Contributor

@JVerwolf JVerwolf commented Feb 21, 2025

Jira: ES-10547

This PR adds a deprecation warning log to the TransportHandshaker when connecting with nodes < v8.18.

@JVerwolf JVerwolf added :Core/Infra/Core Core issues without another label >deprecation labels Feb 21, 2025
@JVerwolf JVerwolf requested review from rjernst, DaveCTurner and a team February 21, 2025 20:33
@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 and others added 3 commits February 21, 2025 12:37

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
…thub.com:JVerwolf/elasticsearch into deprication/add-deprication-warning-to-handshake
@DaveCTurner
Copy link
Contributor

To fix the TransportHandshakerRawMessageTests I would recommend emitting this deprecation in a context that doesn't propagate response headers back over the wire (e.g. under a stashContext() I think?). There's no point in sending the deprecation warning back to the caller IMO - opening a transport connection is a very internal thing. Also, keeping the handshake as simple as possible will make future changes easier if ever a future change is needed.

@JVerwolf
Copy link
Contributor Author

I would recommend emitting this deprecation in a context that doesn't propagate response headers back over the wire

Thanks @DaveCTurner. I'm unfamiliar with how the response headers are logged/reported on the sending node. I'm curious - since this work was motivated by CCR/CCS use-cases, would sending the headers back to the node that was the source of the request be useful here? Or, even if it is, would the headers still be adding complexity to the handshake to the point that this complexity outweigh the benefits?

@DaveCTurner
Copy link
Contributor

would sending the headers back to the node that was the source of the request be useful here?

This PR doesn't directly relate to an actual CCR/CCS request, it's just about the transport handshake. It's true that the transport handshake might under some circumstances be triggered by a cross-cluster request, but often it's just going to be a background thing opening this connection. And most of the time a cross-cluster request will be using a connection that is already established so it won't get the warning anyway.

If you want to see warnings on each CCR/CCS request, you probably need to implement them in the source cluster's RemoteClusterService (by looking at the TransportVersion of the underlying connection). Or maybe in org.elasticsearch.transport.RemoteConnectionManager#wrapConnectionWithRemoteClusterInfo? But tbh this sounds like unnecessary work to me, I have never heard of anyone looking at the warning headers returned to clients, and there are lots of other ways that we have folks hitting deprecated functionality without triggering such a headers, so IMO the important thing is to have the deprecation recorded in the deprecation logs.

JVerwolf and others added 3 commits February 24, 2025 08:48

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
…hake
@JVerwolf JVerwolf marked this pull request as ready for review February 24, 2025 18:06
@elasticsearchmachine
Copy link
Collaborator

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

@elasticsearchmachine elasticsearchmachine added the Team:Core/Infra Meta label for core/infra team label Feb 24, 2025
@JVerwolf
Copy link
Contributor Author

Thanks for the info/context @DaveCTurner. That make sense, I've removed the warning header from the response.

Copy link
Member

@rjernst rjernst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine to me, but please let @DaveCTurner have a final look.

deprecation:
title: Add deprecation warning to `TransportHandshaker`
area: REST API
details: This PR adds a deprecation log to versions < v8.18.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: the details are more what you have in impact. The impact is that users should upgrade any clusters/nodes older than 8.18 in preparation for upgrading to 9.0.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I think this needs more detail. Whatever we write here gets converted into fairly prominent text in the release notes, we should spell out in detail what this change means to avoid causing any confusion to users.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TIL, thanks! I've updated the notes, WDYT?

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few nits. Also this needs to go into 8.x as well as 8.18.

deprecation:
title: Add deprecation warning to `TransportHandshaker`
area: REST API
details: This PR adds a deprecation log to versions < v8.18.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I think this needs more detail. Whatever we write here gets converted into fairly prominent text in the release notes, we should spell out in detail what this change means to avoid causing any confusion to users.


MockLog.assertThatLogger(
MockLog.awaitLogger(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm why did this need to be changed from an immediate assertion?

Copy link
Contributor Author

@JVerwolf JVerwolf Feb 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a prior iteration it was failing when the deprecation log was hit first (I had thought this was because the loggers share the same name, as appears to be convention via other examples in the codebase). However, this is no longer happening - I set this up in a debugger to be sure. I'm not aware of what caused the behaviour difference, but I will revert this to assertThatLogger now that this is no longer causing an issue.

}

private static TransportVersion getRandomIncompatibleTransportVersion() {
return randomBoolean()
private static TransportVersion getRandomIncompatibleTransportVersion(boolean olderThanMinCompatible) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this new parameter needed? It looks like we just pass in a randomBoolean() and don't otherwise care?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a leftover from a prior iteration, I'll remove it, thanks!

@JVerwolf JVerwolf added the auto-backport Automatically create backport pull requests when merged label Feb 26, 2025
…thub.com:JVerwolf/elasticsearch into deprication/add-deprication-warning-to-handshake

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
…hake
@JVerwolf JVerwolf requested a review from DaveCTurner February 26, 2025 19:12
Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Editorial nits only :)

Comment on lines 10 to 12
Users will now see a deprecation log when a remote node, who's version is < v8.18, performs a transport handshake
request with nodes >= v8.18 (e.g. during a CCS/CCR request). The remote cluster will need to be upgraded to >= v8.18
to maintain compatibility with clusters that have been upgraded to v9.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe something like this?

Suggested change
Users will now see a deprecation log when a remote node, who's version is < v8.18, performs a transport handshake
request with nodes >= v8.18 (e.g. during a CCS/CCR request). The remote cluster will need to be upgraded to >= v8.18
to maintain compatibility with clusters that have been upgraded to v9.
Versions 9.0.0 and later of {es} will not support communication with nodes of versions earlier than 8.18.0,
so the ability to connect to nodes of earlier versions is deprecated in this version. This applies both to
communication within a cluster and communication across clusters (e.g. for CCS or CCR).
{es} will report in its deprecation logs each time it opens a connection to a node that will not be supported
from version 9.0.0 onwards. You must upgrade all your clusters to version 8.18.0 or later before upgrading
any of your clusters to 9.0.0 or later.

Bonus points for turning across clusters, CCS, CCR and deprecation logs into links to the relevant docs.

Copy link
Contributor Author

@JVerwolf JVerwolf Feb 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

Bonus points for turning across clusters, CCS, CCR and deprecation logs into links to the relevant docs.

Are you familiar with how to add a link here? (I skimmed the change logs and found no examples). Is this converted to markdown? Will the regular [link](url) apply?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is Asciidoc so [xpack-ccr] should link here for instance.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bah sorry wrong syntax, I meant <<xpack-ccr,{ccr}>>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Much appreciated!

JVerwolf and others added 5 commits February 26, 2025 11:50

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Co-authored-by: David Turner <david.turner@elastic.co>

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Co-authored-by: David Turner <david.turner@elastic.co>

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Co-authored-by: David Turner <david.turner@elastic.co>

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
…hake
@JVerwolf
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/part-2

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
…hake
@JVerwolf JVerwolf merged commit 04917e1 into elastic:8.18 Feb 27, 2025
15 checks passed
@elasticsearchmachine
Copy link
Collaborator

💚 Backport successful

Status Branch Result
8.x

JVerwolf added a commit to JVerwolf/elasticsearch that referenced this pull request Feb 27, 2025
This PR adds a deprecation warning log to the TransportHandshaker when connecting with nodes < v8.18.
JVerwolf added a commit that referenced this pull request Mar 4, 2025

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
This PR adds a deprecation warning log to the TransportHandshaker when connecting with nodes < v8.19.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport Automatically create backport pull requests when merged :Core/Infra/Core Core issues without another label >deprecation Team:Core/Infra Meta label for core/infra team v8.18.1 v8.19.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants