feat: Detect Gateway API version

bjw-s / helm-charts

A collection of Helm charts

https://bernd-schorgers.github.io/helm-charts/

Apache License 2.0

566 stars 106 forks source link

feat: Detect Gateway API version #168

Closed horjulf closed 11 months ago

horjulf commented 1 year ago

Description of the change

Removed

Fixed

Added

Detects the Gateway API version available for each kind in the route object.

Changed

Benefits

Possible drawbacks

Applicable issues

fixes #

Additional information

https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.8.0

Version 0.8.0 of Gateway API drops v1alpha2 version for Gateway, GatewayClass, and HTTPRoute.

Checklist

[x] Title of the PR conforms to the Conventional Commits standard.
[x] Scope of the of the PR title contains the chart name.
[x] Chart version in Chart.yaml has been bumped according to Semantic Versioning.
[x] Chart artifacthub.io/changes changelog annotation has been updated in Chart.yaml. See Artifact Hub documentation for more info.
[x] Variables have been documented in the values.yaml file.

horjulf commented 12 months ago

@bjw-s should I rebase this into the rewrite branch instead ?

WDYT of updating the default to v1beta1 version ? The TCP/UDP along with some other types still use v1alpha2, so its likely useful to keep it configurable.

bjw-s commented 12 months ago

I'm going to be merging the rewrite branch into development tonight or tomorrow. Then I will use development as a staging area to update docs etc before the initial release of 2.0.

horjulf commented 11 months ago

@bjw-s thanks, rebased, should we take the opportunity of the major bump and change the default API version to v1beta1 ?

bjw-s commented 11 months ago

@bjw-s thanks, rebased, should we take the opportunity of the major bump and change the default API version to v1beta1 ?

I'm definitely not against bumping the version. But since I don't use the Gateway API yet I have no idea about any other potential implications of the change, which is why I'm a bit hesitant to make it configurable through the values.yaml

horjulf commented 11 months ago

I'm definitely not against bumping the version. But since I don't use the Gateway API yet I have no idea about any other potential implications of the change, which is why I'm a bit hesitant to make it configurable through the values.yaml

We could bump it directly, however it would break the non-http types (routeKind) since they are only available in v1alpha2.

Basically the >= 0.8.0 spec dropped HTTPRoute from v1alpha2 and is now exclusively available in v1beta1.

Spec at https://gateway-api.sigs.k8s.io/references/spec/#api-specification

Depending on what version of Gateway API CRDs someone is using, they will need different API versions to get it working.

Alternatively we could try to check capabilities and set the version automatically, WDYT ?

horjulf commented 11 months ago

Alternatively we could try to check capabilities and set the version automatically

Something like:

  {{- $routeKind := $routeObject.kind | default "HTTPRoute" -}}
  {{- $apiVersion := "gateway.networking.k8s.io/v1alpha2" -}}
  {{- if $rootContext.Capabilities.APIVersions.Has (printf "gateway.networking.k8s.io/v1beta1/%s" $routeKind) }}
    {{- $apiVersion = "gateway.networking.k8s.io/v1beta1" -}}
  {{- end -}}

bjw-s commented 11 months ago

I'd be cool with a solution like that, that would keep it relatively clean. Hopefully those APIs reach v1 relatively soon to get all the versions aligned again.

horjulf commented 11 months ago

@bjw-s updated to check capabilities.

bjw-s commented 11 months ago

Thanks for this, I've merged in to development so it should be in the next beta soon