-
Notifications
You must be signed in to change notification settings - Fork 492
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
Check ResolvedRefs condition in Gateway conformance tests #2247
Conversation
Hi @levikobi. Thanks for your PR. I'm waiting for a kubernetes-sigs 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. 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.
/lgtm !
/ok-to-test |
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.
/lgtm thanks!
defer to others, make sure nowhere is missed.
/cc |
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 might be missing something, but if are adding these conditions here and not changing https://github.com/kubernetes-sigs/gateway-api/blob/main/conformance/utils/kubernetes/helpers.go#L708-L711
It must say that either our tests fail now or this change will cause them to fail.
What am I missing?
The check only asserts on conditions explicitly listed in the test, so whether existing or missing, the |
But it looks like it compares the number of |
Have a look at https://github.com/kubernetes-sigs/gateway-api/blob/main/conformance/utils/kubernetes/helpers.go#L721 Only if the number of expected conditions is larger than the actual the test will fail. |
Right, thats what I was missing, long day ...😅 Thanks! /lgtm |
/assign @sunjayBhatia |
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 for this PR @levikobi!
I think we should check that all the gateways used in the tests have actually set such a condition to true (Even the gateways used in the HTTPRoute
tests). To do so, we could change this helper to check that the resolvedRefs
is enforced as well.
/cc |
That's a great suggestion, thanks @mlavacca! |
d2adafb
to
6ced935
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.
Thanks @levikobi!
// GatewayAndHTTPRoutesMustBeAccepted waits until: | ||
// 1. The specified Gateway has an IP address assigned to it. | ||
// 2. The route has a ParentRef referring to the Gateway. | ||
// 3. All the gateway's listeners have the ListenerConditionResolvedRefs set to true. |
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.
Do we have any tests that currently expect ListenerConditionResolvedRefs to be false? Since this is such a wide-reaching change, I'm concerned we may break some implementations with this change. Have you run this test against any implementations?
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.
Yes, we do have a bunch of tests that expect ListenerConditionResolvedRefs
to be false:
Type: string(v1beta1.ListenerConditionResolvedRefs), Type: string(v1beta1.ListenerConditionResolvedRefs), Type: string(v1beta1.ListenerConditionResolvedRefs), Type: string(v1beta1.ListenerConditionResolvedRefs),
I tested the changes against Kong's implementation and it works 👍
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.
@robscott I tried running it against Contour's implementation but got some errors. It didn't seem like a problem in the conformance though, but missing assignments of the ResolvedRefs
.
Then I discovered @sunjayBhatia had already opened projectcontour/contour#5668 to address that 😅
Nevertheless I'm glad to hear that Kong and Kuma works.
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.
// GatewayAndHTTPRoutesMustBeAccepted waits until: | ||
// 1. The specified Gateway has an IP address assigned to it. | ||
// 2. The route has a ParentRef referring to the Gateway. | ||
// 3. All the gateway's listeners have the ListenerConditionResolvedRefs set to true. |
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.
Yes, we do have a bunch of tests that expect ListenerConditionResolvedRefs
to be false:
Type: string(v1beta1.ListenerConditionResolvedRefs), Type: string(v1beta1.ListenerConditionResolvedRefs), Type: string(v1beta1.ListenerConditionResolvedRefs), Type: string(v1beta1.ListenerConditionResolvedRefs),
I tested the changes against Kong's implementation and it works 👍
Reason: "", // any reason | ||
} | ||
|
||
GatewayListenersMustHaveCondition(t, c, timeoutConfig, gw.NamespacedName, resolvedRefsCondition) |
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.
Since we are already adding the ResolvedRefs
condition here, I think we should check all the positive-polarity conditions:
ResolvedRefs
Accepted
Programmed
Ideally, GatewayListenersMustHaveCondition
should check the three above conditions to be set and true, before going on. I've created #2415 for this purpose, as it looks like a lack of consistency in our suite. We can address it in another PR, as it is a bit out of scope for this PR, but I wanted to highlight this aspect here as well.
/unhold |
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.
LGTM, passes with Kuma
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: levikobi, michaelbeaumont, mlavacca, Xunzhuo 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 |
Thanks @levikobi! /lgtm |
What type of PR is this?
/kind test
/area conformance
What this PR does / why we need it:
Checks the
ListenerConditionResolvedRefs
value. This is needed to ensure that its value is always set, no matter if theConditionStatus
is true, or false.Which issue(s) this PR fixes:
Fixes #1315
Does this PR introduce a user-facing change?: