sigs.k8s.io/gateway-api@v1.0.0/geps/gep-820.md (about)

     1  # GEP-820: Drop extension points from Route matches
     2  
     3  * Issue: [#820](https://github.com/kubernetes-sigs/gateway-api/issues/820)
     4  * Status: Standard
     5  
     6  ## TLDR
     7  
     8  Drop extension points within Route match block. These extension points are
     9  not well understood.
    10  
    11  ## Goals
    12  
    13  - Drop the extension points within Route match block.
    14  
    15  ## Non-Goals
    16  
    17  - Figure out a replacement solution for the use-case that these extension
    18    points addressed
    19  
    20  ## Introduction
    21  
    22  As the API moves towards `v1alpha2`, the maintainers intend to make the API
    23  standard and forward compatible for the foreseeable future. To that end,
    24  maintainers intend to minimize (eliminate if possible) breaking changes post
    25  `v1alpha2`. This GEP is part of that initiative.
    26  
    27  Extension points for match criteria in Routes were added to enable use-cases
    28  where match criteria defined by implementation was a super-set of match
    29  criteria defined within this API. To the best of our knowledge, even though
    30  extension points were added, no concrete examples or use-cases were known at
    31  that time and none have been discovered so far.
    32  
    33  This proposal advocates removal of these extension points because:
    34  
    35  - It goes against the unwritten design principles this API has followed so far: 
    36  
    37    - minimize number of API types as much as possible
    38    - minimize strongly coupled API types and instead shoot for self-contained
    39      types.
    40    - extension points are introduced with clear use-cases and possibilities in
    41      mind. Vague extension points are avoided as they become harder to maintain.
    42  - It is unlikely that the user experience resulting from defining two k8s
    43    resources for defining a Route will be optimal.
    44  - There is not prior art on splitting match criteria and backend forwarding
    45    semantics (spec.backends) in the community. We believe they are kept together
    46    for good reasons.
    47  
    48  ## API
    49  
    50  The following fields and all associated documentation will be removed:
    51  
    52  - HTTPRouteMatch.ExtensionRef
    53  - TCPRouteMatch.ExtensionRef will be removed. This results in a struct without
    54    any members: TCPRouteMatch. The struct will be kept as it is expected that
    55    more match criterias might be added to L4 routes.
    56  
    57    - Do the same to UDPRoute and TLSRoute
    58  
    59  ## Alternatives
    60  
    61  N/A
    62