Skip to content
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

HTTPRouteServiceTypes Conformance Test Should Not Require EndpointSlices #3379

Open
danehans opened this issue Oct 4, 2024 · 6 comments
Open
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@danehans
Copy link
Contributor

danehans commented Oct 4, 2024

What happened:
My implementation is failing v1.1.0 conformance tests because it does not use EndpointSlices. The backendRef spec does not state that a Service must be backed by an EndpointSlice. Additionally, the HTTPRouteServiceTypes test attempts to model a dual stack Service by manually creating IPv4 and IPv6 EndpointSlices but .spec.ipFamilyPolicy=DualStack is not specified which is inconsistent with the default behavior of this field.

What you expected to happen:
The HTTPRouteServiceTypes conformance test to pass.

How to reproduce it (as minimally and precisely as possible):
N/A

Anything else we need to know?:
N/A

@danehans danehans added the kind/bug Categorizes issue or PR as related to a bug. label Oct 4, 2024
@robscott
Copy link
Member

robscott commented Oct 4, 2024

@danehans Is your implementation using Endpoints instead of EndpointSlices or something else entirely?

@danehans
Copy link
Contributor Author

danehans commented Oct 5, 2024

@robscott yes, the implementation (Gloo Gateway) supports Endpoints. The project plans to support EndpointSlices with https://github.com/solo-io/solo-projects/issues/6910.

@robscott
Copy link
Member

robscott commented Oct 7, 2024

Will let others comment here, but the Endpoints API was effectively deprecated before Gateway API began. I would rather document that we expect implementations to read from EndpointSlices than add conformance tests for Endpoints support.

@robscott
Copy link
Member

robscott commented Oct 7, 2024

/cc @dprotaso

@dprotaso
Copy link
Contributor

dprotaso commented Oct 7, 2024

https://github.com/solo-io/solo-projects/issues/6910

Link 404s

The backendRef spec does not state that a Service must be backed by an EndpointSlice

To Rob's point EndpointSlices have been stable for 3 years and predates the Gateway API v1. The intent of the conformance test was to cover support for this functionality. For example Contour didn't support EndpointSlices until it added support for Gateway API v1.1

Additionally, the HTTPRouteServiceTypes test attempts to model a dual stack Service by manually creating IPv4 and IPv6 EndpointSlices but .spec.ipFamilyPolicy=DualStack is not specified which is inconsistent with the default behavior of this field.

What K8s distro are you testing on? Oddly not setting that field didn't have affect when I did my testing. I did it on GKE.

@danehans
Copy link
Contributor Author

danehans commented Oct 8, 2024

Thanks @robscott and @dprotaso for the feedback. I'm fine requiring EndpointSlices as long as it's documented in the spec so other implementations are not caught off guard.

What K8s distro are you testing on? Oddly not setting that field didn't have affect when I did my testing. I did it on GKE.

I'm testing on kind. I think the key to my point is this section of the referenced doc:

The address family of a Service defaults to the address family of the first service cluster IP range (configured via the --service-cluster-ip-range flag to the kube-apiserver).

When you define a Service you can optionally configure it as dual stack.

Since the Services in the conformance test do not specify ipFamilyPolicy: PreferDualStack or ipFamilyPolicy: RequireDualStack, it can be assumed based on the above doc that SingleStack EndpointSlices are created. Defining the EndpointSlices manually may have worked around this default behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

No branches or pull requests

3 participants