feat: make Gateway.Spec.Addresses.Value optional

[EyalPazz]

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]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: EyalPazz
Once this PR has been reviewed and has the lgtm label, please assign danwinship for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[k8s-ci-robot]

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.

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.

[EyalPazz]

@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]

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

[youngnick]

@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]

Although the +optional is a convention, we have two options to make this optional:

A) A pointer to allow for nil/unspecified values

Suggested change

	// +kubebuilder:validation:MinLength=1
	// +kubebuilder:validation:MaxLength=253
	Value string `json:"value"`
	// +kubebuilder:validation:MinLength=1
	// +kubebuilder:validation:MaxLength=253
	Value *string `json:"value,omitempty"`

B) Allow empty string (no need to distinguish between empty string and unspecified here, so this is likely better)

Suggested change

	// +kubebuilder:validation:MinLength=1
	// +kubebuilder:validation:MaxLength=253
	Value string `json:"value"`
	// +kubebuilder:validation:MaxLength=253
	Value string `json:"value,omitempty"`

Would appreciate some other input on this from others like @youngnick before committing to an approach.

[robscott]

This seems like the fundamental challenge of writing a conformance test for this. As far as I know, none of our conformance tests so far require a specific address type. I like your idea of allowing this to be a configurable flag on the test suite and that's probably sufficient as a starting point. It could be useful to expand this in the future to have a separate SupportedFeature per type though.

[robscott]

This feature name doesn't quite seem right. Maybe useful to describe the address options that will be available after this PR merges:

1. Gateway.spec.addresses unspecified - implementation automatically assigns address(es) of whatever type(s) they choose
2. Gateway.spec.addresses.value unspecified (new in this PR) - implementation automatically assigns address(es) of the type requested (if possible)
3. Gateway.spec.addresses fully specified - implementation automatically assigns address requested (if possible)

So that's a long way of saying that the thing that's new here is the ability to request a type of address without specifying the desired value. So maybe a better name would be GatewayTypedAddressAllocation although that's awfully verbose. Naming is decidedly not my specialty, but something in that general direction would probably be helpful.

[EyalPazz]

can't a fully specified Gateway.spec.addresses also be considered a TypedAddress?

[EyalPazz]

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