HTTPRouteServiceTypes Conformance Test Should Not Require EndpointSlices

[danehans]

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

[robscott]

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

[danehans]

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

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]

/cc @dprotaso

[dprotaso]

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]

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.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.