feat(gateway-api): support full ParentRef fields in HTTPRoute#394
feat(gateway-api): support full ParentRef fields in HTTPRoute#394tuunit merged 2 commits intooauth2-proxy:mainfrom
Conversation
|
Hey, nice and clean PR! Two minor observations: 1. Changelog link mismatch 2. Helm test coverage # tests/httproute_test.yaml
- it: should include sectionName when set
set:
gatewayApi.enabled: true
gatewayApi.gatewayRef.name: my-gw
gatewayApi.gatewayRef.sectionName: https
asserts:
- contains:
path: spec.parentRefs
content:
sectionName: https
any: true
- it: should not include sectionName when empty
set:
gatewayApi.enabled: true
gatewayApi.gatewayRef.name: my-gw
asserts:
- notContains:
path: spec.parentRefs
content:
sectionName: ""
any: trueThis would help prevent regressions and is consistent with the testing patterns for similar optional fields. Not a blocker, but a nice-to-have! |
| {{- end }} | ||
| spec: | ||
| {{- if .Values.gatewayApi.gatewayRef.name }} | ||
| parentRefs: |
There was a problem hiding this comment.
mhhh maybe we should take the opportunity and refactor to support any future option for the parent reference?
so instead of each parameter needing to be part of our chart we should do:
parentRefs:
- {{ toYaml .Values.gatewayApi.gatewayRef | nindent 4 | trim }}https://gateway-api.sigs.k8s.io/reference/spec/#parentreference
There was a problem hiding this comment.
@pierluigilenoci what's your opinion on this? this would mean less maintenance effort on our end for the chart and we would automatically support all reference options
There was a problem hiding this comment.
Totally agree with you here. Passing the whole gatewayRef through with toYaml would reduce maintenance effort on our side and automatically support any future parentReference fields without needing chart changes every time the Gateway API spec evolves. Much cleaner approach.
Signed-off-by: Jarno van de Moosdijk <jarnovandemoosdijk@gmail.com>
tuunit
left a comment
There was a problem hiding this comment.
@jmoosdijk thank you for bringing this up but as suggested by me and Pier we decided to take the opportunity to future proof it and instead just template the whole gatewayRef block as one
Signed-off-by: Jan Larwig <jan@larwig.com>
my pleasure, better to future-proof it indeed! |
Updated by @tuunit:
I repurposed the PR to do the following: Refactored the templating so that the whole object
.Values.gatewayApi.gatewayRefgets templatedtoYamlinstead of needing to maintain every possible current field of the GatewayAPI specification or future once.https://gateway-api.sigs.k8s.io/reference/spec/#parentreference
This way we future proof the helm chart and have less maintenance on our side
Original PRs content:
Checklist: