-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Probe Envoy pods to determine when a ClusterIngress is actually deployed #4734
Probe Envoy pods to determine when a ClusterIngress is actually deployed #4734
Conversation
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.
@JRBANCEL: 0 warnings.
In response to this:
Proposed Changes
See the design doc for details.
TODO
- Working implementation
- Fix existing tests
- Add tests
- Remove the special handling of 404s in E2E tests
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.
The following is the coverage report on pkg/.
|
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.
Mostly superficial items.
@@ -140,6 +176,37 @@ func makeVirtualServiceSpec(ia v1alpha1.IngressAccessor, gateways map[v1alpha1.I | |||
return &spec | |||
} | |||
|
|||
func makeProbeRoute(host string) v1alpha3.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.
Why do we need to add a dummy route? Couldn't we also use our probe? It'll either return activator or queue-proxy but we'd know it works without side-effects I think? Is this to keep the layering strict?
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 do we need to add a dummy route?
It is an invalid Spec without it.
Couldn't we also use our probe? It'll either return activator or queue-proxy but we'd know it works without side-effects I think? Is this to keep the layering strict?
We could. It is simply because it is simpler, has lower latency and more reliable.
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.
Is it guaranteed that the fake route is propageted on the same paths as the actual route? As in: Can we guarantee the actual route is ready and propagated to envoys if we probe the fake route?
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.
We can double check the Istio implementation.
I am assuming that yes, since both routes are bound to the same Istio Gateway, they will be both applied to the same Envoy pods.
An interesting related question is how does Istio apply the config changes?
If it is atomic, good. If not, it is possible that the probe route is applied before the actual route.
e3906a2
to
11432e2
Compare
82db439
to
9b4c24d
Compare
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.
@JRBANCEL: 1 warning.
In response to this:
/lint
/test pull-knative-serving-go-coverage
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.
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.
@JRBANCEL: 1 warning.
In response to this:
/lint
/test pull-knative-serving-go-coverage
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.
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.
@JRBANCEL: 0 warnings.
In response to this:
/lint
/test pull-knative-serving-go-coverage
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.
/test pull-knative-serving-integration-tests |
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.
Should we remove the retries on 404s to assert that this really works as intended?
See
serving/test/v1alpha1/route.go
Lines 77 to 79 in bcd9277
if resp.StatusCode == http.StatusNotFound { | |
return false, nil | |
} |
if you choose to do that: Please leave the helper there even though it doesn't do anything currently. We can use it as a convenient hook until we have baked the networking flakiness some more and are sure we can take the extra wheels off.
Yes, it is planned. See last item in the TODO. |
03135d0
to
754a463
Compare
5467969
to
be182f5
Compare
Needs a rebase. |
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.
Seems like this still has a bunch of debugging stuff in it?
resyncIngressOnVirtualServiceReady := func(vs *v1alpha3.VirtualService) { | ||
// Reconcile when a VirtualService becomes ready | ||
impl.EnqueueLabelOfClusterScopedResource(networking.ClusterIngressLabelKey)(vs) | ||
} |
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.
Could this just be:
resyncIngressOnVirtualServiceReady := impl.EnqueueLabelOfClusterScopedResource(networking.ClusterIngressLabelKey)
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.
Unfortunately, EnqueueLabelOfClusterScopedResource is func(obj interface{}), resyncIngressOnVirtualServiceReady expects a func(*v1alpha3.VirtualService)
be182f5
to
85386cc
Compare
85386cc
to
e8b03d7
Compare
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.
/approve
There is one left over from merge, but otherwise /lgtm
/test pull-knative-serving-istio-1.1-mesh |
/lgtm Let's get it baking. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JRBANCEL, mattmoor, tcnghia 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 🚀 |
/hold cancel |
🚀 |
Fixes #3312 & #1582
Proposed Changes
See the design doc for details.
TODO
Next