feat(http-add-on): allow override of specific component image tag

[ilia-medvedev]

Add possibility to override specific component tag for http-add-on

closes #759

Checklist

• I have verified that my change is according to the deprecations & breaking changes policy
• Commits are signed with Developer Certificate of Origin (DCO - learn more)
• README is updated with new configuration values (if applicable) learn more
• A PR is opened to update KEDA core (repo) (if applicable, ie. when deployment manifests are modified)

Fixes #

[Copilot]

Pull Request Overview

This PR adds the ability to override specific component image tags for the http-add-on Helm chart. Previously, all components (operator, scaler, interceptor) would use the same global image tag, but now each component can have its own tag specified individually while still falling back to the global tag if not set.

• Added component-specific image.tag configuration options for operator, scaler, and interceptor
• Updated deployment templates to use coalesce function for tag resolution with fallback hierarchy
• Updated documentation to reflect the new configuration options

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
http-add-on/values.yaml	Added image.tag configuration options for each component with empty string defaults
http-add-on/templates/operator/deployment.yaml	Updated image tag to use coalesce function with component-specific fallback
http-add-on/templates/scaler/deployment.yaml	Updated image tag to use coalesce function with component-specific fallback
http-add-on/templates/interceptor/deployment.yaml	Updated image tag to use coalesce function with component-specific fallback
http-add-on/README.md	Added documentation for the new component-specific image tag configuration options

[wozniakjan]

I understand the reasoning for putting it here but also there is this block

charts/http-add-on/values.yaml

Lines 220 to 242 in a3087c4

	# configuration for the images to use for each component
	images:
	# tag is the image tag to use for all images.
	# for example, if the operator image is "myoperator" and
	# tag is "mytag", the operator image used will be
	# "myoperator:mytag". `latest` is used to indicate the latest
	# stable release in the official images, `canary` is
	# the build for the latest commit to the `main` branch,
	# and you can target any other commit with `sha-<GIT_SHA[0:7]>`
	# -- Image tag for the http add on. This tag is applied to the images listed in `images.operator`, `images.interceptor`, and `images.scaler`. Optional, given app version of Helm chart is used by default
	tag: ""
	# -- Image name for the operator image component
	operator: ghcr.io/kedacore/http-add-on-operator
	# -- Image name for the interceptor image component
	interceptor: ghcr.io/kedacore/http-add-on-interceptor
	# -- Image name for the scaler image component
	scaler: ghcr.io/kedacore/http-add-on-scaler
	# the kube-rbac-proxy image to use
	kubeRbacProxy:
	# -- Image name for the Kube RBAC Proxy image component
	name: gcr.io/kubebuilder/kube-rbac-proxy
	# -- Image tag for the Kube RBAC Proxy image component
	tag: v0.13.0

I'm wondering if having multiple locations would not be too confusing,

images.tag
operator.image.tag

alternatively we could add

images.operatorTag

wdyt @kedacore/keda-contributors ?

[rickbrouwer]

Looking at this configuration structure, I think the current approach is actually the right design choice.

I think the pattern here follows a logical hierarchy.
The images.tag serves as a global default for all components, while operator.image.tag, scaler.image.tag, and interceptor.image.tag provide component-specific overrides when needed. This gives users flexibility for both.
The commentary given in the code makes it clear to me that it can also be overruled.

[wozniakjan]

but then there are dedicated fields nested under images level, some per component (image), some shared (tag)

I'm still not sure if having newly proposed structure:

images.tag
images.operator
images.interceptor
images.scaler
operator.image.tag
interceptor.image.tag
scaler.image.tag

is better than, let's say:

images.tag
images.operator
images.interceptor
images.scaler
images.operatorTag
images.interceptorTag
images.scalerTag

the interceptorTag is a bit awkward, I fully acknowledge that, but imho the benefit of having image-related definitions follow the pattern of already established nesting under images might be just easier to use and maintain.

[JorTurFer]

Probably we should move in the direction to have global section for global things and placing the component related stuff inside the component section. so maybe we can just add global + componen + default the current way