This repository has been archived by the owner on Mar 29, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First of all: Thank you for a good usable etcdv3 crate!
Now that Tonic got tls-support for the load-balanced client (hyperium/tonic#338), it is possible to add true tls support to this crate as well.
This PR includes:
Some minor Client code refactoring to avoid too much code duplication for when a Channel is established.
Tonic 0.1 -> 0.2 (specifically v0.2.1 is required to get tls-support).
Add optional tls-config to the ClientConfig struct. Note that this change breaks existing clients in that they will have to add
tls: None
explicitly.Update README with a minimal tls example and add a more comprehensive example in examples/tls.rs.
re 3) if you want, we can introduce a builder and/or default-pattern for the ClientConfig struct to avoid breaking clients when new fields are added in the future?
re 4) let me know if you want more or better docs + examples
I've tested this on my own tls-enabled production etcd cluster, with client cert auth enabled as well. I've also done a small regression test with tls disabled to ensure that I didn't break anything.