-
Notifications
You must be signed in to change notification settings - Fork 30
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 support for TLS (conformance test passes) #316
Add support for TLS (conformance test passes) #316
Conversation
Codecov Report
@@ Coverage Diff @@
## main #316 +/- ##
==========================================
+ Coverage 12.91% 16.55% +3.63%
==========================================
Files 20 21 +1
Lines 2958 3172 +214
==========================================
+ Hits 382 525 +143
- Misses 2554 2616 +62
- Partials 22 31 +9
Continue to review full report at Codecov.
|
secret := metav1.PartialObjectMetadata{ | ||
TypeMeta: metav1.TypeMeta{ | ||
Kind: "Secret", | ||
APIVersion: "v1", //metav1.GroupVersion.String(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: corev1.Secret not metav1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whoops accidentally hit the wrong button earlier
change looks good
tl;dr
- I think one of the lint warnings is a legit bug
- We should have a follow up where we create multiple gateways vs updating a single one
_, err := c.gwapiclient.GatewayV1alpha2().Gateways(update.Namespace).Update( | ||
ctx, update, metav1.UpdateOptions{}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Want to open up a new issue about creating multiple gateways vs. updating a single one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_, err := c.gwapiclient.GatewayV1alpha2().Gateways(update.Namespace).Update( | ||
ctx, update, metav1.UpdateOptions{}) | ||
if err != nil { | ||
recorder.Eventf(ing, corev1.EventTypeWarning, "GatewayUpdateFailed", "Failed to update Gateway %s: %v", gwName, err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that these controllers have a default threadiness of 2 - I'd expect many update conflicts since we're updating a single shared resource - this can be addressed by using multiple gateways at a future date.
I'd probably skip recording the event since that might trigger client side throttling since we'll be hitting the API frequently
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, we shouldn't run this controller in HA with the number of buckets being greater than 1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see what you're suggesting. I'll add o TODO and a comment here.
I'll also bring this up with the Gateway API maintainers -- it feels like generating hundreds of Gateways that are supposed to collapse onto the same proxy is probably not right (and doesn't seem to work for at least Contour today), but the one-Gateway model doesn't scale, either.
Filed #318
if len(listeners) > 0 { | ||
// For now, we only reconcile the external visibility, because there's | ||
// no way to provide TLS for internal listeners. | ||
err := c.reconcileGatewayListeners( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious if we should update the gateway listeners first before updating the httproute
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure -- how would you decide which to do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could imagine a poor implementation (of the gateway api) that doesn't trigger reconciliation of existing HTTP routes when ReferenceGrants for certain namespaces are create.
Thus I think I'd prefer to create the listener & grant and update the gateway prior to creating an HTTPRoute.
I'm ok if that's done in a followup PR
for _, h := range tls.Hosts { | ||
listener := gatewayv1alpha2.Listener{ | ||
Name: gatewayv1alpha2.SectionName(h), | ||
Hostname: (*gatewayv1alpha2.Hostname)(&h), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this lint warning seems legit -probably should make a copy of h
otherwise this points to the address space that's updated by the loop iteration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I don't think I've ever had more than one entry in tls.Hosts
, good catch!
for _, l := range listeners { | ||
lmap[string(l.Name)] = l | ||
} | ||
// TODO: how do we track and remove listeners if they are removed from the KIngress spec? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I've added a couple more test cases, going over Dave's comments now. I think my next steps are going to be to figure out what the Contour maintainers expect from |
This repo has two conformance tests:
This PR has 1, but we still need to add a test for 2. I think we can do it in another PR but just wanted to mention about it. Actually 2 still needs to add the test code into |
@@ -28,6 +28,7 @@ import ( | |||
"k8s.io/apimachinery/pkg/runtime" | |||
"k8s.io/apimachinery/pkg/types" | |||
clientgotesting "k8s.io/client-go/testing" | |||
"k8s.io/utils/pointer" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: knative/pkg/ptr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why prefer knative.dev
packages to the upstream k8s ones?
/hold After discussion and testing, it turns out that we can create new Gateway resources in both |
/hold cancel Gateway merging doesn't actually work for at least Contour, and if you have two Gateways, there's no clear way to determine which Gateway the ones without addresses merge to. |
Added some (defaulted) fields to HTTPRoute to avoid controller looping.
/test integration-tests_net-gateway-api_main LGTM. Thank you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -28,6 +28,7 @@ import ( | |||
"k8s.io/apimachinery/pkg/runtime" | |||
"k8s.io/apimachinery/pkg/types" | |||
clientgotesting "k8s.io/client-go/testing" | |||
"k8s.io/utils/pointer" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why prefer knative.dev
packages to the upstream k8s ones?
Ugh, I've somehow screwed up just the kind e2e tests... |
/hold (sorting out the timeout...) |
I missed the rename /hold cancel |
Tests run locally seem to pass now... (I had a cleanup issue I was debugging when I pushed before the |
Hmm, it looks like the conformance tests in the e2e tests are unhappy; I can repro locally with Istio, but not with Contour. Debugging... |
The PR changes lgtm. I'll standby... |
@@ -75,6 +75,8 @@ func makeHTTPRouteSpec( | |||
namespacedNameGateway := gatewayConfig.Gateways[rule.Visibility].Gateway | |||
|
|||
gatewayRef := gatewayv1alpha2.ParentReference{ | |||
Group: (*gatewayv1alpha2.Group)(&gatewayv1alpha2.GroupVersion.Group), | |||
Kind: (*gatewayv1alpha2.Kind)(pointer.String("Gateway")), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the Port
not need to be added as well?
Whoa side note: I was wondering where and how Here are the changes to the latest version, v1.14.1: Istio / Announcing Istio 1.14.1. I wonder if this update would help with the tls stuff. PS: I'll document the info about the Istio version. Since the Istio version being currently used (1.13.2), this other update also adds a TLS related fix: |
Also: Istio has not had a release since upgrading their code to use v0.5.0-rc1 (gateway-api: upgrade to v0.5.0-rc1 by howardjohn · Pull Request #39506 · istio/istio). |
Trying to update Istio is failing: Bump Istio to v1.14.1 by carlisia · Pull Request #330 · knative-sandbox/net-gateway-api |
…sn't support ReferenceGrant yet, and there's no converter.
I foolishly attempted to use the new Pro tip when doing a merge like this:
Once I did this, triage of the tests was a lot easier, because it was clear that it was something in the controller code, not the merge, that had broken the tests. |
/hold cascel |
Tests, including TLS tests, now pass locally. |
This is great, thank you! 🎉 I will add an issue to switch to Thanks for creating all the issues for followup work. Wanted to surface this one comment, I think it requires an issue as well? #316 /lgtm 🚀 |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: carlisia, evankanderson The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/hold cancel |
Changes
Spec.Listener
Still TODO:
Spec.Listener
on delete (separate PR)ingress_test.go
(I got one done, but I want to test the "listener already exists" scenario, at least)/kind enhancement
Fixes #199
Fixes #319
Release Note
Docs