embedetcd: Allow passing in a *tls.Config object for the embedded ETCD Server
The idea is that not only paths to certificate file paths should be possible to define in *embed.Config.ClientTLSInfo and *embed.Config.PeerTLSInfo but also *tls.Config where the certificates could be generated programmatically.
For more details, see the issue: https://github.com/etcd-io/etcd/issues/16339
Hi @RaphSku. Thanks for your PR.
I'm waiting for a etcd-io member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Has there been any movement on this? I'd very much like to see this be merged
Has there been any movement on this? I'd very much like to see this be merged
I'm on it, just had not much time at hand during new year transition but I'm picking up again, hope I will submit a valid PR in approx. 2 weeks.
Oh that's totally fine! Thank you so much for your work, it's geniuely very helpful.
Hey everyone, I needed to refactor and restructure a lot of the code in the embed code. Its passing the tests but I will probably still need to add a few tests, at least another integration test but I wanted to get feedback from you all whether this is going into the right direction or if I am over-engineering it. Thank you all a lot!
I unfortunately dont have the ability to test this right at this second. But I am pinging this thread as I very much want this to be part of the etcd project as it will remove a lot of projects using the antipattern of generating 10 year long certs and enables integration with acme.
cc @awadmhamad
Discussed during sig-etcd triage meeting, @RaphSku do you have capacity to continue this work? If so can you please rebase this pr. Thanks
@jmhbnz I have rebased the PR. Thank you for asking. Yes, I have capacity to work on it. - I still have to fix a few errors that I have introduced by rebasing
@jmhbnz I have fixed the rebase changes. The tests are green again. But as I said, would be good if someone could take a look and point me to the right direction.
/ok-to-test
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: RaphSku Once this PR has been reviewed and has the lgtm label, please assign wenjiaswe for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
/retest
/retest
@jmhbnz All checks have passed, is there someone available that would have time to review this PR?
PR needs rebase.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.