feat: make `Gateway.Spec.Addresses.Value` optional by EyalPazz · Pull Request #3616 · kubernetes-sigs/gateway-api

EyalPazz · 2025-02-16T09:00:54Z

What type of PR is this?
/kind feature

Which issue(s) this PR fixes:
Fixes #3612

Does this PR introduce a user-facing change?:

Make the `value` field in Gateway.Spec.Addresses array optional

k8s-ci-robot · 2025-02-16T09:01:03Z

Hi @EyalPazz. 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.

Details

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-sigs/prow repository.

youngnick

This needs more specification; changing a field to optional is not a breaking change, but it is a big one that will require code updates from all controllers. If you are proposing this, including how to handle empty values for implementations that support it and do not will be important.

We may also need an extended feature to cover this GatewayAddressEmpty or something, so that we can slice the conformance tests accordingly.

youngnick · 2025-02-18T06:01:10Z

 	//
 	// Examples: `1.2.3.4`, `128::1`, `my-ip-address`.
 	//
+	// +optional


This needs some more explanation:

what behavior is expected if an implementation supports an empty Value here?

what behavior is expected if an implementation does not support an empty Value here?

This should then guide you to adding some conformance tests for implementations to test against.

amazing thanks!

+1 to @youngnick's comments, a couple suggestions as a starting point:

If an implementation does support an empty value, we expect them to assign an address matching the type that has been requested with a value of the implementation's choice.

If an implementation does not support an empty value, we expect them to set the Programmed condition in status to False with a reason of AddressNotAssigned. Here's what that reason means as a reference:

gateway-api/apis/v1/gateway_types.go

Lines 874 to 886 in d936258

// This reason is used with the "Programmed" condition when the underlying

// implementation and network have yet to dynamically assign addresses for a

// Gateway.

//

// Some example situations where this reason can be used:

//

// * IPAM address exhaustion

// * Address not yet allocated

//

// When this reason is used the implementation SHOULD provide a clear

// message explaining the underlying problem, ideally with some hints as to

// what actions can be taken that might resolve the problem.

GatewayReasonAddressNotAssigned GatewayConditionReason = "AddressNotAssigned"

I think the extra doc requirement here got missed. I'd still like to see some description of what should happen in both cases on this field, if it's supported and not.

Thanks for catching this @youngnick! @EyalPazz any chance you can squeeze this in in the next day or two? Really hoping we can fit this into v1.3 if possible, and we'll need to cut a RC pretty soon.

EyalPazz · 2025-02-19T14:09:16Z

@youngnick, this isn't ready for merge yet, i wanted your opinion on injecting a valid type value to the test suite
Should we take a similar approach to the GatewayStaticAddresses test?

EyalPazz · 2025-02-19T14:16:50Z

@shaneutt , i'd also appreciate your opinion here, as i saw you wrote the PLACEHOLDER_**_ADDRS hacks

youngnick · 2025-02-20T00:36:21Z

@youngnick, this isn't ready for merge yet, i wanted your opinion on injecting a valid type value to the test suite Should we take a similar approach to the GatewayStaticAddresses test?

That seems reasonable, yes.

robscott

Thanks for taking this on @EyalPazz!

robscott · 2025-02-20T02:02:13Z

 	//
 	// Examples: `1.2.3.4`, `128::1`, `my-ip-address`.
 	//
+	// +optional


+1 to @youngnick's comments, a couple suggestions as a starting point:

If an implementation does support an empty value, we expect them to assign an address matching the type that has been requested with a value of the implementation's choice.

If an implementation does not support an empty value, we expect them to set the Programmed condition in status to False with a reason of AddressNotAssigned. Here's what that reason means as a reference:

gateway-api/apis/v1/gateway_types.go

Lines 874 to 886 in d936258

// This reason is used with the "Programmed" condition when the underlying

// implementation and network have yet to dynamically assign addresses for a

// Gateway.

//

// Some example situations where this reason can be used:

//

// * IPAM address exhaustion

// * Address not yet allocated

//

// When this reason is used the implementation SHOULD provide a clear

// message explaining the underlying problem, ideally with some hints as to

// what actions can be taken that might resolve the problem.

GatewayReasonAddressNotAssigned GatewayConditionReason = "AddressNotAssigned"

EyalPazz · 2025-02-24T12:26:10Z

@youngnick @robscott can you please re-review this?

robscott

Thanks @EyalPazz!

robscott · 2025-03-05T17:45:25Z

Hey @EyalPazz, I chatted with @youngnick about this and we agreed that it would make sense to move the conformance test for this into a follow up PR. The rationale is that as long as we have a clearly defined API spec for this, the conformance test would be covering with 99+% of implementations already do (automatically assign an IP address to a Gateway), so it's not quite as critical as we'd initially thought.

Will you have time to update the PR in the next day or two to reflect this new smaller scope? Would love to get this into v1.3 if possible.

EyalPazz · 2025-03-05T18:57:51Z

Hey @EyalPazz, I chatted with @youngnick about this and we agreed that it would make sense to move the conformance test for this into a follow up PR. The rationale is that as long as we have a clearly defined API spec for this, the conformance test would be covering with 99+% of implementations already do (automatically assign an IP address to a Gateway), so it's not quite as critical as we'd initially thought.

Will you have time to update the PR in the next day or two to reflect this new smaller scope? Would love to get this into v1.3 if possible.

Yea for sure, i'll do it tomorrow morning

EyalPazz · 2025-03-06T08:48:17Z

Should be ok now :) @robscott

robscott · 2025-03-07T06:23:30Z

Thanks @EyalPazz! Will leave final LGTM for @youngnick or someone else.

/approve

k8s-ci-robot · 2025-03-07T06:23:38Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: EyalPazz, robscott

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [robscott]

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

robscott · 2025-03-14T03:09:18Z

I missed something when I approved. Adding a hold until #3616 (comment) is addressed.

/hold

robscott

Thanks @EyalPazz! This mostly LGTM, just needs another codegen run and a bit of clarification in the spec.

robscott · 2025-03-16T17:45:51Z

Thanks @EyalPazz! This LGTM, will defer to @youngnick for final approval.

/hold cancel

youngnick · 2025-03-16T22:43:45Z

Thanks for the extra changes @EyalPazz, great work.

/lgtm

) * feat: make `Gateway.Spec.Addresses.Value` optional * wip: test mock * feat: flag injection & change `GatewayAddress` -> `GatewaySpecAddress` * add `omitempty` to the value * chore: update codegen * fix: type validation and minLength * chore: remove conformance test for now * complete rename of `GatewayAddress` -> `GatewaySpecAddress` * fix: improve docs for value field * fix: value field doc

k8s-ci-robot added kind/feature Categorizes issue or PR as related to a new feature. release-note Denotes a PR that will be considered when it comes time to generate release notes. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Feb 16, 2025

k8s-ci-robot requested review from robscott and shaneutt February 16, 2025 09:00

k8s-ci-robot added needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. labels Feb 16, 2025

shaneutt added this to the v1.3.0 milestone Feb 17, 2025

youngnick requested changes Feb 18, 2025

View reviewed changes

shaneutt removed their request for review February 18, 2025 11:17

EyalPazz force-pushed the make-addresses-value-optional branch from 26365be to d39cc82 Compare February 19, 2025 14:04

k8s-ci-robot removed the do-not-merge/invalid-commit-message Indicates that a PR should not merge because it has an invalid commit message. label Feb 19, 2025

EyalPazz requested a review from youngnick February 19, 2025 14:06

EyalPazz force-pushed the make-addresses-value-optional branch from d39cc82 to 581ba80 Compare February 19, 2025 14:11

robscott reviewed Feb 20, 2025

View reviewed changes

EyalPazz requested a review from robscott February 24, 2025 12:26

youngnick mentioned this pull request Feb 27, 2025

Adding GEP-3539: Gateway API to Expose Pods on Cluster-Internal IP Address (ClusterIP Gateway) #3608

Closed

EyalPazz added 2 commits March 3, 2025 09:35

feat: flag injection & change GatewayAddress -> GatewaySpecAddress

9b4c8d1

add omitempty to the value

687de42

EyalPazz force-pushed the make-addresses-value-optional branch from 4cd24c2 to 687de42 Compare March 3, 2025 07:36

chore: update codegen

cc7a71b

robscott reviewed Mar 5, 2025

View reviewed changes

Comment thread apis/v1/shared_types.go

Comment thread apis/v1/gateway_types.go Outdated

EyalPazz added 3 commits March 6, 2025 10:32

fix: type validation and minLength

afb0490

chore: remove conformance test for now

1d7df0f

complete rename of GatewayAddress -> GatewaySpecAddress

35f890d

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 7, 2025

fix: improve docs for value field

eb95ca1

robscott reviewed Mar 15, 2025

View reviewed changes

Comment thread apis/v1/gateway_types.go Outdated

fix: value field doc

d9c6ec1

EyalPazz requested a review from robscott March 15, 2025 11:08

k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 16, 2025

k8s-ci-robot assigned youngnick Mar 16, 2025

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Mar 16, 2025

k8s-ci-robot merged commit 09cfd3e into kubernetes-sigs:main Mar 16, 2025

github-project-automation Bot moved this from Review to Done in Gateway API Pipeline Mar 16, 2025

This was referenced Mar 18, 2025

REQUEST: New membership for @EyalPazz kubernetes/org#5477

Closed

Add test for optional address value in httproute #3687

Closed

bjee19 mentioned this pull request Sep 13, 2025

fix: fix validation and wording when making gateway spec addresses value optional #4084

Merged

	// This reason is used with the "Programmed" condition when the underlying
	// implementation and network have yet to dynamically assign addresses for a
	// Gateway.
	//
	// Some example situations where this reason can be used:
	//
	// * IPAM address exhaustion
	// * Address not yet allocated
	//
	// When this reason is used the implementation SHOULD provide a clear
	// message explaining the underlying problem, ideally with some hints as to
	// what actions can be taken that might resolve the problem.
	GatewayReasonAddressNotAssigned GatewayConditionReason = "AddressNotAssigned"

Conversation

EyalPazz commented Feb 16, 2025

Uh oh!

k8s-ci-robot commented Feb 16, 2025

Uh oh!

youngnick left a comment

Choose a reason for hiding this comment

Uh oh!

youngnick Feb 18, 2025

Choose a reason for hiding this comment

Uh oh!

EyalPazz Feb 18, 2025

Choose a reason for hiding this comment

Uh oh!

robscott Feb 20, 2025

Choose a reason for hiding this comment

Uh oh!

youngnick Mar 14, 2025

Choose a reason for hiding this comment

Uh oh!

robscott Mar 14, 2025

Choose a reason for hiding this comment

Uh oh!

EyalPazz commented Feb 19, 2025

Uh oh!

EyalPazz commented Feb 19, 2025

Uh oh!

youngnick commented Feb 20, 2025

Uh oh!

robscott left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

robscott Feb 20, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

EyalPazz commented Feb 24, 2025

Uh oh!

robscott left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

robscott commented Mar 5, 2025

Uh oh!

EyalPazz commented Mar 5, 2025

Uh oh!

EyalPazz commented Mar 6, 2025

Uh oh!

robscott commented Mar 7, 2025

Uh oh!

k8s-ci-robot commented Mar 7, 2025

Uh oh!

robscott commented Mar 14, 2025

Uh oh!

robscott left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

robscott commented Mar 16, 2025

Uh oh!

youngnick commented Mar 16, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants