Add "Programmed" Gateway condition, move "Ready" to extended conformance

[LCaparelli]

What type of PR is this?
/kind feature
/kind api-change

What this PR does / why we need it: Make necessary changes to Gateway and Listener conditions in order to implement GEP-1364.

Which issue(s) this PR fixes:

Fixes #1454

Does this PR introduce a user-facing change?:

Added "Programmed" Gateway and Listener conditions, moved "Ready" to extended conformance

[k8s-ci-robot]

Hi @LCaparelli. 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 /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.

[robscott]

Thanks @LCaparelli! This mostly LGTM, would appreciate a review from @youngnick as well though.

[robscott]

/ok-to-test

[youngnick]

The API changes look great, but I think there's quite a bit more work to do to update all the conformance tests.

@LCaparelli, did you want to round out the conformance test updates in this PR, or should one of us do it in a follow-up?

[LCaparelli]

@youngnick, @robscott thanks for the review!

@LCaparelli, did you want to round out the conformance test updates in this PR, or should one of us do it in a follow-up?

Oh, I kinda just searched for usages of ListenerReasonReady and GatewayConditionReady consts and replaced them, it's what I understood from the original issue's:

Update all conformance tests that check the "Ready" Gateway or Listener condition to check "Programmed" instead.

Am I missing other places where this is checked but is not using the consts? Or did you mean something else?

If you mean other tests that were not initially in the issue's scope I'm happy to help and can either do it here or in a follow-up.

[youngnick]

Thanks for the update @LCaparelli!

Hmm, I just went and checked, and I was thinking of this function call:

gateway-api/conformance/utils/kubernetes/helpers.go

Lines 135 to 139 in 9568c67

	// GatewayAndHTTPRoutesMustBeReady waits until the specified Gateway has an IP
	// address assigned to it and the Route has a ParentRef referring to the
	// Gateway. The test will fail if these conditions are not met before the
	// timeouts.
	func GatewayAndHTTPRoutesMustBeReady(t *testing.T, c client.Client, timeoutConfig config.TimeoutConfig, controllerName string, gw GatewayRef, routeNNs ...types.NamespacedName) string {

But it turns out that's actually already checking for Accepted instead, so is misnamed. Would you be able to tidy that up please?

Additionally, it looks like this function needs an update:

gateway-api/conformance/utils/kubernetes/helpers.go

Lines 92 to 95 in 9568c67

	// NamespacesMustBeReady waits until all Pods and Gateways in the provided
	// namespaces are marked as ready. This will cause the test to halt if the
	// specified timeout is exceeded.
	func NamespacesMustBeReady(t *testing.T, c client.Client, timeoutConfig config.TimeoutConfig, namespaces []string) {

It's looking for the Gateway to be Ready , but we're not using the constant, just the string Ready. May be worth a case-sensitive search for Ready as well to find any other uses in the conformance/ directory.

Sorry to be picky, but I want to make sure we squash all the Ready references in one go.

[LCaparelli]

Yup, no worries at all @youngnick! Thanks for the additional pointers, I'll take a more thorough look

[LCaparelli]

@youngnick @robscott I think I got it all covered this time, please take a look at the last 4 commits when you can. Thanks again for the guidance!

[youngnick]

I can't see anything else this time, nice work @LCaparelli. I'll approve and let @robscott or @shaneutt do the final LGTM.

This is the one that will break v0.5.1 conformance though, i think.

/approve

[shaneutt]

Looks good, couple small language nits.

[LCaparelli]

Thanks @shaneutt, fixed!

[shaneutt]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: LCaparelli, shaneutt, youngnick

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:

• OWNERS [shaneutt,youngnick]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment