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

[FEATURE] Introduce new OpenSearchTransport based on Apache HttpClient 5 #281

Merged
merged 1 commit into from
Jan 13, 2023

Conversation

reta
Copy link
Collaborator

@reta reta commented Nov 25, 2022

Signed-off-by: Andriy Redko andriy.redko@aiven.io

Description

Get rid of the dependency on OpenSearch core. Introducing new OpenSearchTransport based on Apache HttpClient 5, with no dependencies on OpenSearch's core RestClient.

Issues Resolved

PoC for #262

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@reta
Copy link
Collaborator Author

reta commented Nov 25, 2022

@dblock @dlvenable the PoC for getting rid of the dependency on OpenSearch core, basically more or less the amount of code we would need to copy / paste from core (I think I could reduce it a bit but that would not be a game changer there). It should help us to assess the go / no-go decision.

Copy link
Member

@dblock dblock left a comment

Choose a reason for hiding this comment

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

I love it. It's a lot smaller than I thought it would be and it's mostly boilerplate (+ tests?).

@reta
Copy link
Collaborator Author

reta commented Nov 28, 2022

I love it. It's a lot smaller than I thought it would be and it's mostly boilerplate (+ tests?).

Sure, a few sketches needed to make it compete and testable (just wanted to hear your opinion first), I'll wrap it up shortly.

@reta
Copy link
Collaborator Author

reta commented Dec 1, 2022

@dblock @VachaShah got stuck on this one #47 :(

@andrross
Copy link
Member

andrross commented Dec 2, 2022

I love this as well. Removing the dependency on core clearly outweighs any downside to code duplication, in my opinion.

@reta reta force-pushed the issue-262 branch 5 times, most recently from e0cf2c2 to 051b2b1 Compare January 11, 2023 19:16
@reta reta changed the title [WIP] [FEATURE] Get rid of the dependency on OpenSearch core [FEATURE] Get rid of the dependency on OpenSearch core Jan 11, 2023
@reta reta marked this pull request as ready for review January 11, 2023 19:34
@reta
Copy link
Collaborator Author

reta commented Jan 11, 2023

@dblock @andrross @VachaShah I think the POC is ready

Copy link
Member

@dblock dblock left a comment

Choose a reason for hiding this comment

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

import org.opensearch.client.transport.Version;

public class ApacheHttpClient5Options implements TransportOptions {
private static final String USER_AGENT = "User-Agent";
Copy link
Member

Choose a reason for hiding this comment

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

I found it interesting that the client does not declare things like user-agent as constants. Since this is only used once, maybe we should too? I noticed you don't for "Accept" :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I have largely copied it from RestClientOptions, we probably should have constants, I agree

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done

String ua = String.format(
Locale.ROOT,
"opensearch-java/%s (Java/%s)",
Version.VERSION == null ? "Unknown" : Version.VERSION.toString(),
Copy link
Member

Choose a reason for hiding this comment

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

Nit: should never be null

Copy link
Collaborator Author

@reta reta Jan 12, 2023

Choose a reason for hiding this comment

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

@dblock you will be surprised but [1]:

    /**
     * This library's version, read from the classpath. Can be {@code null} if the version resource could not be read.
     */
    @Nullable
    public static final Version VERSION;

[1] https://github.com/opensearch-project/opensearch-java/blob/main/java-client/src/main/java/org/opensearch/client/transport/Version.java#L138-L139

@reta
Copy link
Collaborator Author

reta commented Jan 12, 2023

This is real progress!

What's the path to delete https://github.com/opensearch-project/opensearch-java/blob/f1fbe833d7cd925018b7ed3f9cd1c0684e25b993/java-client/build.gradle.kts#LL149C5-L149?

Thanks @dblock ! This is what we have discussed here [1], basically easy steps:

  • for 3.0.0, make RestClient optional (as the dependency)
  • recommend to use Apache HttpClient 5 based transport instead

[1] opensearch-project/OpenSearch#5424 (comment)

dblock
dblock previously approved these changes Jan 12, 2023
Copy link
Member

@dblock dblock left a comment

Choose a reason for hiding this comment

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

I'm good to merge this or wait to get the actual cut-off done on main.

@andrross
Copy link
Member

This is real progress!
What's the path to delete https://github.com/opensearch-project/opensearch-java/blob/f1fbe833d7cd925018b7ed3f9cd1c0684e25b993/java-client/build.gradle.kts#LL149C5-L149?

Thanks @dblock ! This is what we have discussed here [1], basically easy steps:

* for 3.0.0, make RestClient optional (as the dependency)

* recommend to use Apache HttpClient 5 based transport instead

[1] opensearch-project/OpenSearch#5424 (comment)

I may be confused, but that's the plan for removing the legacy rest client from OpenSearch right? Why can't we remove the dependency on OpenSearch from opensearch-java right now?

@reta
Copy link
Collaborator Author

reta commented Jan 13, 2023

This is real progress!
What's the path to delete https://github.com/opensearch-project/opensearch-java/blob/f1fbe833d7cd925018b7ed3f9cd1c0684e25b993/java-client/build.gradle.kts#LL149C5-L149?

Thanks @dblock ! This is what we have discussed here [1], basically easy steps:

* for 3.0.0, make RestClient optional (as the dependency)

* recommend to use Apache HttpClient 5 based transport instead

[1] opensearch-project/OpenSearch#5424 (comment)

I may be confused, but that's the plan for removing the legacy rest client from OpenSearch right? Why can't we remove the dependency on OpenSearch from opensearch-java right now?

That would be hard breaking change: since we never deprecated RestClientTransport, just removing it without any notice is probably not a good idea. We at least could start with deprecating RestClientTransport, and removing in the next version, I think that would be less impactful.

@dblock
Copy link
Member

dblock commented Jan 13, 2023

Thanks @reta @andrross and @dlvenable! Let's talk about what we want to merge. I think we should

  1. Make this PR as "added OpenSearchTransport", document how to use it, merge
  2. In a separate PR, "deprecate RestClientTransport (and possibly other classes)", and mark the deprecated classes as such, document the recommended way to use the client ([FEATURE] Deprecate RestClientTransport #326)
  3. Backport 1) and 2) to 2.x, continue a 2.x line of releases.
  4. In 3.0/main delete the deprecated code.

@reta
Copy link
Collaborator Author

reta commented Jan 13, 2023

Is it possible to do this in a way where the public-facing part of the API doesn't have to change when the underlying Apache HttpClient changes? i.e. call the public API ApacheHttpClientTransport That way users don't have to change their code when the dependency is updated.

This is not really possible, the Apache HttpClient 4 and Apache HttpClient 5 are very different: we could hide some (like fe HttpHost) but everything from credentials to TLS configuration does require package change. However, if we do ApacheHttpClient4Transport in 2.x, we could keep it in 3.x as well - zero change for users.

@reta reta force-pushed the issue-262 branch 2 times, most recently from d593b64 to b557835 Compare January 13, 2023 18:19
@reta reta changed the title [FEATURE] Get rid of the dependency on OpenSearch core by introducing Apache HttpClient 5 based transport [FEATURE] Introduce new OpenSearchTransport based on Apache HttpClient 5 Jan 13, 2023
@andrross
Copy link
Member

Is it possible to do this in a way where the public-facing part of the API doesn't have to change when the underlying Apache HttpClient changes? i.e. call the public API ApacheHttpClientTransport That way users don't have to change their code when the dependency is updated.

This is not really possible, the Apache HttpClient 4 and Apache HttpClient 5 are very different: we could hide some (like fe HttpHost) but everything from credentials to TLS configuration does require package change. However, if we do ApacheHttpClient4Transport in 2.x, we could keep it in 3.x as well - zero change for users.

Makes sense. I'm slowly getting up to speed here :) So HttpClient 4 and 5 are actually distinct packages that can exists side-by-side (org.apache.httpcomponents.httpclient vs org.apache.httpcomponents.client5.httpclient5). Is that right? Assuming that's true, why is it a breaking change to add the new HttpClient 5 dependency in 2.x?

@reta
Copy link
Collaborator Author

reta commented Jan 13, 2023

 Makes sense. I'm slowly getting up to speed here :) So HttpClient 4 and 5 are actually distinct packages that can exists side-by-side (org.apache.httpcomponents.httpclient vs org.apache.httpcomponents.client5.httpclient5). Is that right?

That's right.

Assuming that's true, why is it a breaking change to add the new HttpClient 5 dependency in 2.x?

This is true. There are no concerns regarding breaking change, my concern is "new dependencies are going to be introduced", it may be very surprising to see that within minor version update (may be I am overly cautious).

@andrross
Copy link
Member

Assuming that's true, why is it a breaking change to add the new HttpClient 5 dependency in 2.x?

This is true. There are no concerns regarding breaking change, my concern is "new dependencies are going to be introduced", it may be very surprising to see that within minor version update (may be I am overly cautious).

The tl;dr is that this PR will add a new dependency (Apache HttpClient 5) and create a new ApacheHttpClient5Transport class that will be the new recommended approach for creating a client, as opposed to the existing RestClientTransport that depends on OpenSearch core. The specific question is whether adding the HttpClient5 dependency should be considered a breaking change, or can it be added in the next minor release on 2.x? @wbeckler @dlvenable @dblock What do you think?

@reta
Copy link
Collaborator Author

reta commented Jan 13, 2023

Assuming that's true, why is it a breaking change to add the new HttpClient 5 dependency in 2.x?

This is true. There are no concerns regarding breaking change, my concern is "new dependencies are going to be introduced", it may be very surprising to see that within minor version update (may be I am overly cautious).

The tl;dr is that this PR will add a new dependency (Apache HttpClient 5) and create a new ApacheHttpClient5Transport class that will be the new recommended approach for creating a client, as opposed to the existing RestClientTransport that depends on OpenSearch core. The specific question is whether adding the HttpClient5 dependency should be considered a breaking change, or can it be added in the next minor release on 2.x? @wbeckler @dlvenable @dblock What do you think?

Please note that right now Apache HttpClient 5 comes with OpenSearch core 3.0.0, nothing is added to opensearch-java (as you can see, the build dependencies have not changed in this pull request).

Signed-off-by: Andriy Redko <andriy.redko@aiven.io>
Copy link
Member

@andrross andrross left a comment

Choose a reason for hiding this comment

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

Thanks @reta, this looks good to me!

I believe the remaining open question is whether to backport this to 2.x (with a slight change to explicitly declare the HttpClient5 dependencies) or instead introduce an ApacheHttpClient4Transport. In either case this change will be needed on main.

@dlvenable
Copy link
Member

@reta , I did not actually see a dependency change in this PR (no modification to the build file). It seems that we are pulling in Apache HTTP Client 5 via a transitive dependency.

We may want to explicitly add this dependency now that the project itself depends on it.

Thanks @reta, this looks good to me!

I believe the remaining open question is whether to backport this to 2.x (with a slight change to explicitly declare the HttpClient5 dependencies) or instead introduce an ApacheHttpClient4Transport. In either case this change will be needed on main.

Is this dependency already in the 2.x line? If so, we are not adding a new dependency. If not, we can make this optional at runtime to address the concern of adding new dependencies. End users would need to add it to their build files to use the transport.

@dlvenable
Copy link
Member

The specific question is whether adding the HttpClient5 dependency should be considered a breaking change, or can it be added in the next minor release on 2.x?

In my opinion, this is not breaking since it is compatible with HttpClient4. If we really want, it is possible to make this an optional dependency on 2.x using feature variants. End users would have to add this dependency or get a runtime error.

@andrross
Copy link
Member

@dlvenable We are getting HttpClient5 on the main branch via a transitive dependency. For the 2.x branch it would have to be added a new dependency.

@dblock dblock merged commit 9657df6 into opensearch-project:main Jan 13, 2023
@dblock
Copy link
Member

dblock commented Jan 13, 2023

I merged it. @reta backport or not?

@reta
Copy link
Collaborator Author

reta commented Jan 13, 2023

I merged it. @reta backport or not?

Let me try to do this on Monday (the automatic one won't work, we need explicit dependencies), thanks @dblock !

reta added a commit to reta/opensearch-java that referenced this pull request Jan 16, 2023
…earch-project#281)

Signed-off-by: Andriy Redko <andriy.redko@aiven.io>

Signed-off-by: Andriy Redko <andriy.redko@aiven.io>
reta added a commit to reta/opensearch-java that referenced this pull request Jan 16, 2023
…earch-project#281)

Signed-off-by: Andriy Redko <andriy.redko@aiven.io>

Signed-off-by: Andriy Redko <andriy.redko@aiven.io>
reta added a commit to reta/opensearch-java that referenced this pull request Jan 16, 2023
…earch-project#281)

Signed-off-by: Andriy Redko <andriy.redko@aiven.io>

Signed-off-by: Andriy Redko <andriy.redko@aiven.io>
reta added a commit that referenced this pull request Jan 17, 2023
…#328)

Signed-off-by: Andriy Redko <andriy.redko@aiven.io>

Signed-off-by: Andriy Redko <andriy.redko@aiven.io>

Signed-off-by: Andriy Redko <andriy.redko@aiven.io>
@BrendonFaleiro BrendonFaleiro mentioned this pull request Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants