Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions charts/kong/CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,12 @@
# Changelog

## Unreleased

### Changes

* Align `IngressClass.spec.controller` with `ingressController.ingressClass`
when using multiple controllers or a non-default ingress class.

Copilot AI Apr 24, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This changelog entry describes the alignment change, but it doesn’t call out the operational upgrade impact: IngressClass.spec.controller is immutable, so users with an existing chart-managed IngressClass and a non-default ingressController.ingressClass will need to delete/recreate the IngressClass before upgrading. Similarly, changing the Gateway API controller name may require updating existing GatewayClass controllerName values. Please add explicit upgrade notes here (and ideally in UPGRADE.md) to prevent failed upgrades / unexpected controller non-reconciliation.

Suggested change
when using multiple controllers or a non-default ingress class.
when using multiple controllers or a non-default ingress class.
Upgrade note: `IngressClass.spec.controller` is immutable. If you have an
existing chart-managed `IngressClass` and use a non-default
`ingressController.ingressClass`, you may need to delete and recreate the
`IngressClass` before upgrading. If you use Gateway API resources, you may
also need to update existing `GatewayClass.spec.controllerName` values to
match the new controller name after upgrade, otherwise the controller may
not reconcile those resources.

Copilot uses AI. Check for mistakes.

## 3.2.0

### Changes
Expand Down
2 changes: 1 addition & 1 deletion charts/kong/templates/ingress-class.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -29,5 +29,5 @@ metadata:
labels:
{{- include "kong.metaLabels" . | nindent 4 }}
spec:
controller: ingress-controllers.konghq.com/kong
controller: ingress-controllers.konghq.com/{{ .Values.ingressController.ingressClass }}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is ok 👍

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After reading this second time I need to take back my comment: this is not about the ingress class here but about the controller. While we could possibly link these 2 (like you did) I'd prefer not to do this.

What I think could be a good way forward and not introducing a breaking change for users is to add a new field in values.yaml (possibly: .ingressController.controllerName, defaulting to kong) and use that here.

This would also prevent what copilot mentioned about controller being immutable (by setting the default to what was already hardcoded in the template).

Comment on lines 31 to +32

Copilot AI Apr 24, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IngressClass.spec.controller is immutable. For any existing chart-managed IngressClass created with the old fixed controller value (ingress-controllers.konghq.com/kong), upgrading with a non-default ingressController.ingressClass will make Helm try to patch this field and the upgrade will fail unless the IngressClass is deleted/recreated. Consider adding template logic to detect an existing IngressClass with a different .spec.controller and fail with a clear message (or otherwise document/handle the required delete-and-recreate flow).

Copilot uses AI. Check for mistakes.
{{- end -}}