Support installing and managing KEDA HTTP Add-on

[Fedosin]

Summary

The KEDA OLM Operator currently manages lifecycle operations for the main KEDA installation, but it does not provide a way to install or maintain the KEDA HTTP Add-on (https://github.com/kedacore/http-add-on).
This feature request proposes extending the operator so that users can deploy and manage the HTTP Add-on as part of the standard KEDA installation flow.

Motivation

The HTTP Add-on is a first-class part of the KEDA ecosystem, enabling request-based autoscaling for HTTP workloads. In environments where KEDA is installed and maintained through OLM, having a separate, manually managed installation process for the HTTP Add-on leads to inconsistencies, extra operational overhead, and difficulties keeping versions in sync.

Adding native operator support would:

• Provide a unified installation experience for KEDA users.
• Ensure version compatibility between KEDA and the HTTP Add-on.
• Simplify upgrades and day-2 operations.
• Align with how other KEDA components are already managed in OLM environments.

Feature Proposal

Introduce support for installing and maintaining the HTTP Add-on through the KEDA OLM Operator. There are two potential design paths:

Option A: Introduce a new dedicated controller + CRD

• Create a new CRD, e.g. HTTPAddOn, responsible for specifying desired configuration of the HTTP Add-on.
• Implement a new controller in the operator to reconcile that CRD and manage install/upgrade/remove flows.
• Allow the CRD to be optionally enabled or disabled so that clusters not using the HTTP Add-on remain unaffected.

Option B: Extend the existing KEDA CRD

• Add a new section to the existing CRD indicating that the HTTP Add-on should be deployed and configured.
• Reuse the existing controller logic where appropriate, with additional reconciliation steps for HTTP Add-on resources.
• Automatically coordinate version compatibility between KEDA core and the add-on.

Open Questions

• Should the HTTP Add-on lifecycle be strictly tied to the KEDA core version, or configurable independently?
• Is the team leaning toward a standalone CRD (strong separation of concerns) or an extension of the main KEDA configuration (simpler user experience)?
• Should default configuration values be applied automatically, or should the operator require explicit user input?

Expected Outcome

Once implemented, users applying or updating the KEDA operator via OLM will be able to declaratively manage both KEDA and the HTTP Add-on using GitOps or standard cluster operators, ensuring the two components remain aligned and reducing manual operational burden.