Repository navigation
Support secret-based and pre-shared certs at the same time - #641
Conversation
|
Hi @michallowicki. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
|
/assign @rramkumar1 |
8de142c to
a3c8a07
Compare
|
/ok-to-test |
There was a problem hiding this comment.
"...secret-based certs and tests that all should be used"
There was a problem hiding this comment.
I don't follow this. If you remove the pre-shared cert then why would you expect it after Ensure()?
There was a problem hiding this comment.
Removed this part of the test.
Pre-shared cert can be removed from target proxy but retained in the loadbalancer, verifyCertAndProxyLink() verifies that.
There was a problem hiding this comment.
What are you trying to test by adding the secret again? Seems unnecessary to me but I could be missing something.
There was a problem hiding this comment.
Good point, removed this part of the test.
The idea was to also test reverting the update, but it's already tested by TestPreSharedToSecretBasedCertUpdate.
There was a problem hiding this comment.
So, I just remembered that we have a function in pkg/utils/utils.go to join errors. Can you use that instead?
Also the caller of this function can take care of wrapping the error with "Errors ensuring SSL certs"
a3c8a07 to
25d4165
Compare
There was a problem hiding this comment.
nit: Can you use a different name for SelfLink here?
There was a problem hiding this comment.
Can we add a test for a case where 10 ingress secrets/certs are specified and lb is created. Then as an update, 10 pre-shared certs are specified. From the code, looks like we will prefer the pre-shared certs first correct? So all the 10 certs that were initially used will be replaced by the 10 new pre-shared certs that were specified. Correct me if i misunderstood this. I chose 10 because we use that as a fake limit in some other tests.
It would be good to have a test validating this so we can document the behavior.
There was a problem hiding this comment.
Good point, added a test for this case:
10 ingress secrets/certs are specified and lb is created.
Then 5 pre-shared are created (reaching FakeCertLimit of 15).
Trying to use all 15 certs fails, and old setup with 10 secret-base certs is not overwritten. This is treated the same as trying to use 15 certs of the same type - if there are more certs than the TargetProxyCertLimit of 10, the update fails.
After removing 5 secret-based certs, the remaining 5 secret-based and 5 pre-shared certs can be used.
There was a problem hiding this comment.
Thanks for verifying the behavior and adding the new tests!
Since the update fails due to targetProxy limit exceeding, the certs used by ingress will not be modified, I missed that in my initial comment.
25d4165 to
7c50e1a
Compare
There was a problem hiding this comment.
Can you reword this as "which is the limit for the fake target proxy"?
There was a problem hiding this comment.
reword this as "limit of 15 certs which is the fake certs quota"
There was a problem hiding this comment.
nit: This isn't your change, but if you wouldn't mind, can you rename "FakeCertLimit" to "FakeCertQuota"? We can do it in a follow up change too, if that's easier.
There was a problem hiding this comment.
Thanks for verifying the behavior and adding the new tests!
Since the update fails due to targetProxy limit exceeding, the certs used by ingress will not be modified, I missed that in my initial comment.
7c50e1a to
59b9fc1
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: michallowicki, rramkumar1 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This should allow for a no-downtime migration from secret-based to pre-shared certs, as the secret-based cert will be still used until the secret is removed.