Skip to content

GEP-820: Drop extension points from Route matches

  • Issue: #820
  • Status: Standard

TLDR

Drop extension points within Route match block. These extension points are not well understood.

Goals

  • Drop the extension points within Route match block.

Non-Goals

  • Figure out a replacement solution for the use-case that these extension points addressed

Introduction

As the API moves towards v1alpha2, the maintainers intend to make the API standard and forward compatible for the foreseeable future. To that end, maintainers intend to minimize (eliminate if possible) breaking changes post v1alpha2. This GEP is part of that initiative.

Extension points for match criteria in Routes were added to enable use-cases where match criteria defined by implementation was a super-set of match criteria defined within this API. To the best of our knowledge, even though extension points were added, no concrete examples or use-cases were known at that time and none have been discovered so far.

This proposal advocates removal of these extension points because:

  • It goes against the unwritten design principles this API has followed so far:

  • minimize number of API types as much as possible

  • minimize strongly coupled API types and instead shoot for self-contained types.
  • extension points are introduced with clear use-cases and possibilities in mind. Vague extension points are avoided as they become harder to maintain.
  • It is unlikely that the user experience resulting from defining two k8s resources for defining a Route will be optimal.
  • There is not prior art on splitting match criteria and backend forwarding semantics (spec.backends) in the community. We believe they are kept together for good reasons.

API

The following fields and all associated documentation will be removed:

  • HTTPRouteMatch.ExtensionRef

  • TCPRouteMatch.ExtensionRef will be removed. This results in a struct without any members: TCPRouteMatch. The struct will be kept as it is expected that more match criterias might be added to L4 routes.

  • Do the same to UDPRoute and TLSRoute

Alternatives

N/A