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 ssl_options to consumers #413

Merged
merged 8 commits into from
Oct 16, 2020

Conversation

markusfeyh
Copy link
Contributor

This allows the pass-through of ssl_options when starting workers starting a consumer or consumer group.

@markusfeyh
Copy link
Contributor Author

Failing tests from 7181920 are unrelated and passed locally as well as when re-running the build

@markusfeyh
Copy link
Contributor Author

Giving this a bump since it's pretty minor, could you take a look?
@joshuawscott @jbruggem

Copy link
Collaborator

@dantswain dantswain left a comment

Choose a reason for hiding this comment

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

Sorry I haven't had a chance to look at in depth yet. I meant to dig into it because I could have sworn there was already a way to do this.

I'll try to find time to make sure. In the meantime, I had a couple comments/questions. Thanks!

@@ -24,6 +24,26 @@ defmodule KafkaEx.ConsumerGroup.Test do
assert consumer_group == :no_consumer_group
end

test "create_worker allows us to pass in use_ssl and ssl_options options" do
Application.put_env(:kafka_ex, :use_ssl, true)
Copy link
Collaborator

Choose a reason for hiding this comment

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

You'd need to reset this to the previous value at the end of your test.

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, will do

custom_ssl_options = [
cacertfile: File.cwd!() <> "/ssl/ca-cert-custom",
certfile: File.cwd!() <> "/ssl/cert-custom.pem",
keyfile: File.cwd!() <> "/ssl/key-custom.pem"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we just reuse the files we already have? I'm also not sure how the test would pass if we don't configure the test broker to use these.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yah, these are the same as the existing files we already have, just the filename is different so it can be validated in the test that a different file is being used.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ahh that makes sense. It would be nice if we could document that somehow (even if it's just in a comment in this test). There's about a 100% chance that some day someone will wonder why we have a duplicate set of keys with different names and get very confused. Probably me because I'll forget 😂. Another option might be to create a copy of the files as part of the test run and then delete them during clean up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added some documentation, and realized it would be even more explicit to use a symbolic file links to prevent duplicate files combined with a comment. Would that work?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

On second though, I also really like your proposal @dantswain of creating and deleting the files to not confuse the repo since others may look at those certs for examples of how to configure client.

ssl/ca-cert-custom Outdated Show resolved Hide resolved
@markusfeyh
Copy link
Contributor Author

Could you give it another round of review @dantswain ?

name
)
|> Enum.count()
wait_for(fn ->
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 will explicitly raise an error if it the comparison does not return true which fails the test

  1) test can create a topic (KafkaEx.Server0P10P1AndLater.Test)
     test/integration/server0_p_10_and_later_test.exs:9
     ** (RuntimeError) too many tries waiting for condition
     code: wait_for(fn ->
     stacktrace:
       test/test_helper.exs:165: TestHelper.wait_for_value/5
       test/integration/server0_p_10_and_later_test.exs:27: (test)

@markusfeyh
Copy link
Contributor Author

Giving this a bump going into next week, could you take a look?

@markusfeyh
Copy link
Contributor Author

I saw @joshuawscott provided an option to specify the worker and then pass that in as part of the fetch_options. The downside of that approach is that we would lose the benefit of the ConsumerGroup.Manager supervision tree.

The impact of that is that we would have to maintain more code around using the library, as a pose to this PR which would allow different SSL options to be passed through as with other consumers in the library.

I'm trying to think of a strong reason why this is a bad idea, and see mostly positives. Could you provide feedback?

@joshuawscott
Copy link
Member

I think the SSL options do more properly go into the worker rather than fetch options, since there are other interactions (metadata, commit) that aren't fetch.

Copy link
Member

@joshuawscott joshuawscott left a comment

Choose a reason for hiding this comment

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

This LGTM, I'll let @dantswain weigh in though

@Argonus
Copy link
Contributor

Argonus commented Oct 16, 2020

Hi @dantswain / @joshuawscott
Any news when this can be merged?

@joshuawscott joshuawscott merged commit a1bd360 into kafkaex:master Oct 16, 2020
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