feat(http-add-on): ClusterRole and ClusterRoleBinding use release name

[paihu]

http-add-on's ClusterRole and ClusterRoleBinding use .Release.Name instead of .Chart.Name

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 #843

[linkvt]

Hi @paihu ,
thanks for the PR - I am out of office next week but will review the PR afterwards.
Notes for myself/reviewers: We have to consider whether this change is OK now (IMO yes), whether it is complete (didn't check) and if we want to improve names of other resources, possibly also just for v1 release where breakingh changes are more OK.

[Fedosin]

Review

Context: Issue #843 reports that installing the http-add-on chart multiple times (e.g., once per namespace with different watchNamespace values) fails because cluster-scoped ClusterRole/ClusterRoleBinding resources all get the same name from .Chart.Name (keda-add-ons-http), causing collisions. This PR switches those names to .Release.Name so each installation gets unique cluster-scoped resource names.

What's good

• Correct scope -- The change is properly limited to cluster-scoped resources (ClusterRole, ClusterRoleBinding). Namespace-scoped resources (Role, RoleBinding, ServiceAccount, Deployment, Service) are left as-is, which is correct since they don't collide across namespaces.
• Internal references are consistent -- ClusterRoleBinding roleRef.name fields are updated to match the renamed ClusterRoles. ServiceAccount references in subjects are correctly left unchanged (SAs are namespace-scoped, and the namespace field in subjects disambiguates them).
• Aligns with existing patterns -- The _helpers.tpl already uses .Release.Name for the app.kubernetes.io/instance label, so this follows an established convention.

Issues

1. Incomplete -- aggregate ClusterRoles are missed

rbac-aggregateclusterroles.yaml defines two more cluster-scoped ClusterRoles that still use .Chart.Name:

# rbac-aggregateclusterroles.yaml line 6
name: {{ .Chart.Name }}-edit

# rbac-aggregateclusterroles.yaml line 30
name: {{ .Chart.Name }}-view

These would also collide in a multi-install scenario. They should be updated to .Release.Name for consistency, or an explanation provided for why they're excluded.

2. Breaking change -- orphaned resources on upgrade

This is a breaking change for existing installations. When a user runs helm upgrade, Helm tracks resources by kind + name. Renaming these resources means Helm will create new ClusterRoles/ClusterRoleBindings (with .Release.Name) and leave the old ones (with .Chart.Name) orphaned in the cluster. Users would need to manually clean up the stale resources.

This should be documented in the chart's upgrade notes or changelog. The PR checklist item "README is updated with new configuration values" is unchecked -- at minimum, a note about the upgrade impact and manual cleanup steps would be valuable.

3. Minor: name label inconsistency in ClusterRoleBinding metadata

In the ClusterRoleBinding labels, some labels are changed and others aren't:

labels:
    keda.sh/addon: {{ .Chart.Name }}          # stays .Chart.Name
    app: {{ .Chart.Name }}                    # stays .Chart.Name
    name: {{ .Release.Name }}-rolebinding     # changed to .Release.Name

The name label is updated to .Release.Name (makes sense -- it should match the resource name), while keda.sh/addon and app stay as .Chart.Name (also reasonable -- they describe the chart identity). This is fine but worth a conscious acknowledgement that the labeling convention is intentional.

Suggestions

1. Also update rbac-aggregateclusterroles.yaml to use .Release.Name.
2. Add a note in the README or CHANGELOG about the breaking change and cleanup steps for upgrades.
3. Consider linking Fixes #843 in the PR body (it's currently empty).

[paihu]

Thanks for the review.

I had initially excluded aggregateclusterroles because it differs from the other ClusterRoles in that it grants permissions to users outside the chart and can be toggled on/off via values.yaml, so I was treating it as a breaking change.

For the ClusterRoles I changed in this PR, my assumption was that they're only used by roles within the chart, so the change wouldn't be breaking. However, if this change is also considered breaking, then I think it makes sense to update aggregateclusterroles along with the rest.