Conformance Tests: TLSRoute Passthrough

[candita]

This issue is intended to track conformance test development for TLSRoute Passthrough. Comment below if you're interested in working on covering any of these areas.

Core Capabilities:

• [x] Valid TLSRoute with 1 backendRef/rule
• [ ] Valid TLSRoute with 1 backendRef/Rule and matching SNI hostname
• [ ] Valid TLSRoute with 1 backendRef/Rule and matching SNI hostname with wildcard prefix
• [ ] Valid TLSRoute with 1 backendRef/Rule and matching SNI hostname for both Listener and TLSRoute with intersecting hostname - [ ] Invalid TLSRoute - no backendRef/rule doesn't become Ready - [ ] Invalid TLSRoute - invalid backendRef/rule doesn't become Ready (some or all from sublist?) - [ ] Missing Rule - [ ] Missing Port - [ ] Kind, if not nil, is also not Service - [ ] Multi ParentRef sections names not set - [ ] Multi ParentRef sections names not unique - [ ] SNI hostname invalid - IP address
  • [ ] TLSRoute must not be Accepted for any invalid hostnames; ‘Accepted’ condition False in RouteParentStatus - [ ] SNI hostname invalid - not RFC1123, not wildcard prefix
  • [ ] Matching SNI hostname for both Listener and TLSRoute without intersecting hostname
  • [ ] TLSRoute hostname that doesn’t match the Listener hostname is ignored - [ ] More than 16 hostnames - [ ] More than 16 rules - [ ] More than 16 backendRef -[ ] Invalid TLSRoute with 1 backendRef/Rule that doesn’t exist performs no default forwarding
• [ ] Invalid TLSRoute with invalid BackendObjectReference performs no default forwarding (some or all from sublist?) - [ ] Name not set - [ ] Kind not set
  • [ ] Namespace (of backend) not set
  • [ ] Namespace (of backend) missing ReferenceGrant - [ ] Port missing when Kind is Service
• [ ] Invalid TLSRoute with filters that provide response must REJECT connection or return 500 status (some or all from sublist?)
  • [ ] Rejections must observe weight, e.g. if 50% might have been delivered, then 50% should be rejected instead
• [ ] For a Listener setting mode: "terminate", attempting to set TLSRoute in AllowedRoutes.kinds would yield a ListenerConditionType Accepted with status: false and ListenerConditionReason InvalidRouteKinds
  • [ ] this could probably be validated by webhook too
• [ ] For a Listener setting mode: "terminate", TLSRoute should not be present in ListenerStatus.SupportedKinds
• [ ] Attempting to attach a TLSRoute to a Listener setting mode: "terminate" should yield RouteConditionType Accepted with status: false and RouteConditionReason NotAllowedByListeners on the TLSRoute

[robscott]

Thanks @candita! I think it would be worth differentiating between tests of our API validation and tests of the actual underlying implementation. At least so far, I've been working with the assumption that conformance tests are only intended to cover implementation details, not our CRD or webhook validation. https://github.com/kubernetes-sigs/gateway-api/issues/1514 has a bit more context on that discussion though.

[youngnick]

I agree that for now, if one of these cases is covered by CRD validation, webhook validation, or both, we can check it off, and then come back to testing it as part of sorting out #1514.

[candita]

Does this adjusted list make more sense @robscott @youngnick ?

[youngnick]

Yep, that looks great, thanks @candita!

[mikemorris]

Suggested additions to the list of conformance tests since we've discussed disallowing mode: "terminate" with TLSRoute:

• [ ] for a Listener setting mode: "terminate", attempting to set TLSRoute in AllowedRoutes.kinds would yield a ListenerConditionType Accepted with status: false and ListenerConditionReason InvalidRouteKinds
  • [ ] this could probably be validated by webhook too
• [ ] for a Listener setting mode: "terminate", TLSRoute should not be present in ListenerStatus.SupportedKinds
• [ ] attempting to attach a TLSRoute to a Listener setting mode: "terminate" should yield RouteConditionType Accepted with status: false and RouteConditionReason NotAllowedByListeners on the TLSRoute

[youngnick]

Those additions look great, thanks @mikemorris.

[candita]

@mikemorris

Suggested additions to the list of conformance tests since we've discussed disallowing mode: "terminate" with TLSRoute:

• [ ] for a Listener setting mode: "terminate", attempting to set TLSRoute in AllowedRoutes.kinds would yield a ListenerConditionType Accepted with status: false and ListenerConditionReason InvalidRouteKinds

  • [ ] this could probably be validated by webhook too
• [ ] for a Listener setting mode: "terminate", TLSRoute should not be present in ListenerStatus.SupportedKinds
• [ ] attempting to attach a TLSRoute to a Listener setting mode: "terminate" should yield RouteConditionType Accepted with status: false and RouteConditionReason NotAllowedByListeners on the TLSRoute

I added these to the description so they wouldn't get lost. Can you provide more detail about this could probably be validated by webhook too? It's just a comment, not a test, right?

[sunjayBhatia]

Added an issue here https://github.com/kubernetes-sigs/gateway-api/issues/2153 which is a follow up for https://github.com/kubernetes-sigs/gateway-api/pull/2076

Looks relevant to include as part of the checklist here

[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

[youngnick]

/remove-lifecycle rotten

[youngnick]

This is a blocker for #2643.

[candita]

@sunjayBhatia

Added an issue here #2153 which is a follow up for #2076

Looks relevant to include as part of the checklist here

That is this one, correct?

• Invalid TLSRoute with invalid BackendObjectReference performs no default forwarding (some or all from sublist?)

[mikemorris]

Updating my prior comment about passthrough and terminate - there's not a conclusive determination yet on what the expected behavior should be for this, and we'll probably need to figure that out as part of encoding anything in conformance.

Refs Slack thread, #1474 and #2111

/cc @kate-osborn

[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

[candita]

/remove-lifecycle-stale

[shaneutt]

/lifecycle frozen /priority important-soon