feat(trait): Auto-discover KEDA Kafka scaler from Camel URIs

[pkalsi97]

This PR implements automatic discovery of KEDA triggers (Kafka for now) from Camel integration source URIs.
Closes #6312

Changes

pkg/trait/
├── keda.go
├── keda_test.go
└── keda/
    ├── mapper.go
    ├── mapper_test.go
    ├── uri_parser.go
    └── scalers/
        ├── kafka.go
        └── kafka_test.go

• Added E2E tests for all 3 cases:
  • Pure auto-discovery
  • Manual trigger + auto-discovery (different types)
  • Auto-discovery with metadata merge

Behavior

When the KEDA trait is enabled, the system automatically extracts component information from from() URIs and generates corresponding KEDA ScaledObject triggers without requiring manual trigger configuration.

Behavior	Description
Default	Auto-discovery enabled (auto: true) when no manual triggers specified
Merged	Manual triggers of different types coexist with auto-discovered ones
Precedence	Manual triggers of same type override auto-discovered ones
Opt-out	Set keda.auto: false to disable auto-discovery

Supported Components

Camel Component	KEDA Scaler	Mapped Parameters
kafka	kafka	topic, bootstrapServers, consumerGroup

Note: This initial implementation supports Kafka only. The extensible ScaleMapper interface allows adding more scalers (aws-sqs, rabbitmq) in future.

Example

traits:
  keda:
    enabled: true
    # triggers auto-discovered from: kafka:my-topic?brokers=my-kafka:9092&groupId=my-group

With autoMetadata for extra KEDA params:

traits:
  keda:
    enabled: true
    autoMetadata:
      kafka:
        lagThreshold: "100"

[squakez]

Excellent work. The mapping is fine and we can add as much as we can support eventually. However, it seems we're missing to include this in the trait logic itself - did you forget to commit some file by any chance?

Then, some question. Here we're supporting the mapping of only a few parameters. How should we deal with additional parameters?

As for the structure of the code, I think it would be preferrable to have a pkg/trait/keda directory to have it better identified the resources. As for the mapping, it would be also likely convenient to have a ScaleMapper interface and a single scaler implementation for each. So, in /pkg/trait/keda/scalers we can have kakfa.go, sqs.go, ... having the specific logic of each self contained.

As a first POC we can keep it though, but we should add some documentation to clarify this is a WIP.

[github-actions]

✔️ Unit test coverage report - coverage increased from 51.6% to 51.7% (+0.1%)

[pkalsi97]

@squakez Thanks for the initial review. Yes some files did not get committed.

Even I was thinking there is a certain flaw with my current implementation -
The current implementation is an all or nothing type where either client can opt for auto discovery or simply add the triggers for all resources manually and no auto discovery will happen, I can think of 3 cases.

Case	Scenario	Behavior
1	No triggers specified	Auto-discover all triggers from URI
2	Triggers specified	If trigger type is not auto-discoverable → add it. If trigger type matches auto-discoverable resource → use user's trigger (skip auto-discovery for that type). Auto-discover remaining supported types from URI.
3	Extra params for auto-discoverable type	User can pass additional metadata params that get merged with auto-discovered params or we support all of them

What do you think about this merged approach ?

Secondly regarding structure of the code: Definitely can work on a better interface based approach as you suggested with ScaleMapper interface

pkg/trait/keda/
├── mapper.go
├── uri_parser.go
└── scalers/
    ├── kafka.go
    ├── sqs.go
    └── rabbitmq.go

[github-actions]

✔️ Unit test coverage report - coverage increased from 51.6% to 51.7% (+0.1%)

[squakez]

@pkalsi97 yeah, I think the approach you've proposed is more consistent. Also the structure is exactly what I was thinking. When you continue with the development, my suggestion is that you start with the development of a single mapper (ideally, kafka). It's better to have a strong and complete reference, and we can later add more mappers on demand.

[pkalsi97]

@squakez sure. Thanks for the input!

[pkalsi97]

@squakez I have refactored the implementation as suggested, also updated the PR description and title. Thanks.

[squakez]

Very cool work indeed. Thanks for the contribution!

[github-actions]

✔️ Unit test coverage report - coverage increased from 50.6% to 50.7% (+0.1%)