IPAddress.spec.gateway should be optional for IPv6 and maybe for IPv4

[schrej]

Due to a sluggish implementation of the validation of IPAddress resources, the .spec.gateway field is currently required.

While this does make sense for IPv4, where you almost always provide a gateway when using DHCP (which the IPAM contract is essentially replacing), it does not for IPv6, which supports other methods like Router Advertising to configure a gateway.

We currently have two implementations, one making it completely optional, the other only for IPv6.
#8506 (entirely optional)
#8525 (ipv6 optional)

I'm in favor of making it optional for ipv6, but keep requiring it for ipv4.

For context: kubernetes-sigs/cluster-api-ipam-provider-in-cluster#70

cc @fabriziopandini @sbueringer

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[christianang]

+1 for optional ipv6, but required for ipv4.

[vincepri]

+1 for ipv6, while it's not unheard of networks without a gateway (from a technical point of view), it's extremely uncommon in Kubernetes environments

[sbueringer]

Thx for writing up the issue. Also agree with only making it optional for ipv6

[christianang]

Do we think at this point we'd be happy to merge #8525 then?

[schrej]

I ran this by our networking colleagues, and it turns out that we are actually using IPv4 without gateways at the moment (we don't even have network addresses, don't ask me how that works).
To be fair, our setup is probably quite unusual (each cluster node is acting as a router), so this might be a rare use case, and we could definitely work around gateways being required for ipv4.

Sorry for bringing this up so late. I think they told me before, but our networking is such a rabbit hole that I missed that while thinking about it in CAPI context.

I would therefore go with optional for both, ipv4 and ipv6, to allow maximum flexibility.
Since this isn't really an interaction point for users, I think it's a lot more meaningful to do proper validation on provider level, where users will actually see the error when applying configuration. On that level validation can then also be configurable if necessary.

The benefit of validating at this level is that providers can rely on the field to be present.

[sbueringer]

While this does make sense for IPv4, where you almost always provide a gateway when using DHCP (which the IPAM contract is essentially replacing)

To be fair, you were writing "almost" always :). I guess we found one of those cases now where a gateway is not required. Sounds fine to me to make gateway optional for both.

[christianang]

👍 making gateway optional for both is fine with me as well.

[sbueringer]

Okay so let's go ahead with: #8506