Skip to content

Conversation

@v-jizhang
Copy link
Contributor

@v-jizhang v-jizhang commented Mar 26, 2021

Cherry-pick of trinodb/trino#4165,
trinodb/trino#2591 and
trinodb/trino#3331

Co-authored-by: Martin Traverso mtraverso@gmail.com

== RELEASE NOTES ==

ElasticSearch Connector Changes
* Add support for Elasticsearch user and password authentication.
   :issue:`15909`

Copy link
Contributor

@aweisberg aweisberg left a comment

Choose a reason for hiding this comment

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

Thanks for working on this.

So I am generally speaking +1 on what I see in terms of the functional changes, but there is some additional backporting and simplification we can do in the tests (only use high level rest client, remove embedded elastic search server) and I would like to block the PR on including those as well.

Copy link
Contributor

Choose a reason for hiding this comment

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

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 not be omitted, added. Thanks

Copy link
Contributor

Choose a reason for hiding this comment

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

We should remove EmbeddedElasticsearchNode like they did in Trino if we can.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I'll do it in another PR.

@v-jizhang v-jizhang requested a review from aweisberg April 7, 2021 23:05
@aweisberg aweisberg requested a review from zhenxiao April 7, 2021 23:13
@aweisberg
Copy link
Contributor

@zhenxiao adding you for review since you have done a lot of ES work.

@aweisberg
Copy link
Contributor

I mixed up the two links I meant trinodb/trino@bbe718d

Copy link
Collaborator

@zhenxiao zhenxiao left a comment

Choose a reason for hiding this comment

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

looks good. a few minor things

Copy link
Collaborator

Choose a reason for hiding this comment

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

shall we make /usr/share/elasticsearch/config/ constant?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, thanks.

Copy link
Collaborator

Choose a reason for hiding this comment

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

how about password as PASSWORD?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Let's keep it the same as Trino

Copy link
Collaborator

Choose a reason for hiding this comment

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

make elasticsearch:7.8.0 a constant, or 7.8.0 a version constant?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure. I'll change it. Thanks

@aweisberg
Copy link
Contributor

@zhenxiao how much is consistency worth with Trino? A lot of these choices for constants are just what Trino did.

@v-jizhang
Copy link
Contributor Author

Thanks for working on this.

So I am generally speaking +1 on what I see in terms of the functional changes, but there is some additional backporting and simplification we can do in the tests (only use high level rest client, remove embedded elastic search server) and I would like to block the PR on including those as well.

That should be done in another PR and it's on my list.

@aweisberg
Copy link
Contributor

I don't think it should be a separate PR just because it introduces the additional complexity in this PR instead of doing it the way Trino did it? We are mixing together two change sets from Trino and not taking the entirety of both so we end up with this mixed result.

@v-jizhang
Copy link
Contributor Author

I don't think it should be a separate PR just because it introduces the additional complexity in this PR instead of doing it the way Trino did it? We are mixing together two change sets from Trino and not taking the entirety of both so we end up with this mixed result.

I'll port testcontainers changes and get rid of embedded Elasticsearch node and make this PR simpler. Thanks

Copy link
Contributor

@aweisberg aweisberg left a comment

Choose a reason for hiding this comment

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

Looks this is relying on EmbeddedElasticSearchNode. We should get rid of the duplication between that and the older RestClient.

@v-jizhang
Copy link
Contributor Author

Looks this is relying on EmbeddedElasticSearchNode. We should get rid of the duplication between that and the older RestClient.

Yes, I'll rebase and get rid of it after #15937

@v-jizhang v-jizhang requested a review from aweisberg May 17, 2021 23:09
Copy link
Contributor

@aweisberg aweisberg left a comment

Choose a reason for hiding this comment

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

Can you squash/fixup so it is the three core commits. Add password authentication. Remove embedded elastic search server, and add the comment from Martin? You don't need to change the order just make it roughly analogous to what happened in Trino.

Also add co-authors to the latter two commits.

Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we end up needing JNA? I don't see it as a dependency in Trino.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Presto has that dependency:
Require upper bound dependencies error for net.java.dev.jna:jna:5.2.0 paths to dependency are:
+-com.facebook.presto:presto-elasticsearch:0.254-SNAPSHOT
+-org.testcontainers:testcontainers:1.15.2
+-org.rnorth.visible-assertions:visible-assertions:2.1.2
+-net.java.dev.jna:jna:5.2.0
and
+-com.facebook.presto:presto-elasticsearch:0.254-SNAPSHOT
+-org.testcontainers:testcontainers:1.15.2
+-com.github.docker-java:docker-java-transport-zerodep:3.2.7
+-net.java.dev.jna:jna:5.5.0

Copy link
Contributor

Choose a reason for hiding this comment

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

Why remove setNodeCount?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Trino removed that and other counts in trinodb/trino#3267. I should do it in another PR. Added it back. Thanks

@v-jizhang v-jizhang requested a review from aweisberg May 20, 2021 16:27
@aweisberg
Copy link
Contributor

OK, well if you can get the commit history cleaned up and get a passing test run I can approve it :-)

Cherry-pick of trinodb/trino#4165 and
trinodb/trino#2591

Co-authored-by: Martin Traverso <mtraverso@gmail.com>
@v-jizhang
Copy link
Contributor Author

OK, well if you can get the commit history cleaned up and get a passing test run I can approve it :-)

Done. Please review.

Copy link
Contributor

@aweisberg aweisberg left a comment

Choose a reason for hiding this comment

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

We don't really want to squash all the commits together into a single commit. That erased the history and merged together unrelated changes. We just want to squash the extra modification commits used to be there https://github.com/prestodb/presto/commits/d3013b66e4c904a08fae8faf72cf8128bef2f2d7

Is it possible to restore it without it being a herculean task? Ideally if we cherry-pick three commits we end up with the same three commits on our end.

@v-jizhang
Copy link
Contributor Author

We don't really want to squash all the commits together into a single commit. That erased the history and merged together unrelated changes. We just want to squash the extra modification commits used to be there https://github.com/prestodb/presto/commits/d3013b66e4c904a08fae8faf72cf8128bef2f2d7

Is it possible to restore it without it being a herculean task? Ideally if we cherry-pick three commits we end up with the same three commits on our end.

I didn't find a way to restore the commits. If you like, I can redo it. Thanks

@v-jizhang v-jizhang requested a review from aweisberg July 20, 2021 15:11
@v-jizhang v-jizhang marked this pull request as draft July 26, 2021 18:22
@v-jizhang
Copy link
Contributor Author

Replaced by #16524.

@v-jizhang v-jizhang closed this Jul 27, 2021
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.

3 participants