squakez commented on code in PR #6917: URL: https://github.com/apache/camel-k/pull/6917#discussion_r4379339245
########## proposals/keda-connection-beans.adoc: ########## @@ -0,0 +1,195 @@ +--- +title: Discovering connection configuration for KEDA scalers +authors: + - "@knockknock10" +creation-date: 2026-10-25 +last-updated: 2026-10-25 +status: draft +see-also: + - https://github.com/apache/camel-k/issues/6910 + - https://github.com/apache/camel-k/pull/6893 + - https://github.com/apache/camel-k/issues/6890 +replaces: [] +superseded-by: [] +--- + +[[keda-connection-beans]] += Discovering connection configuration for KEDA scalers + +== Summary + +Camel K can automatically create KEDA triggers from supported consumer endpoint URIs, but a scaler may need connection details configured outside the URI. Those details can live in Camel component properties or in a named bean (for example, a connection factory referenced by a component). The current scaler-mapping contract does not expose a resolved Camel registry or bean configuration to the mapper. + +This proposal recommends keeping automatic discovery static and deterministic. As an initial step, scaler mappings may consume explicit, statically available Integration properties in addition to the endpoint URI. For connection beans, Camel K should first assess a narrowly scoped resolver for declarative property-based bean definitions and references. It should not instantiate arbitrary application beans in the operator. If the required configuration cannot be derived consistently from Camel K's declarative model, the Camel community should assess a Camel Core metadata contract that exposes relevant configuration without requiring Camel K to execute the integration. + +This is a design proposal only; it does not introduce a runtime resolver or change the scaler interface. + +== Problem statement + +A KEDA scaler reads metadata to poll an external system and decide when to scale an Integration. Automatic discovery currently starts with a Camel consumer URI, but not every scaler's required metadata is present in that URI. + +Connection information can be configured in several ways, including: Review Comment: I like this part. Let's use each bullet point to clarify what is implementable and what not. ########## proposals/keda-connection-beans.adoc: ########## @@ -0,0 +1,195 @@ +--- +title: Discovering connection configuration for KEDA scalers +authors: + - "@knockknock10" +creation-date: 2026-10-25 +last-updated: 2026-10-25 +status: draft +see-also: + - https://github.com/apache/camel-k/issues/6910 + - https://github.com/apache/camel-k/pull/6893 + - https://github.com/apache/camel-k/issues/6890 +replaces: [] +superseded-by: [] +--- + +[[keda-connection-beans]] += Discovering connection configuration for KEDA scalers + +== Summary + +Camel K can automatically create KEDA triggers from supported consumer endpoint URIs, but a scaler may need connection details configured outside the URI. Those details can live in Camel component properties or in a named bean (for example, a connection factory referenced by a component). The current scaler-mapping contract does not expose a resolved Camel registry or bean configuration to the mapper. + +This proposal recommends keeping automatic discovery static and deterministic. As an initial step, scaler mappings may consume explicit, statically available Integration properties in addition to the endpoint URI. For connection beans, Camel K should first assess a narrowly scoped resolver for declarative property-based bean definitions and references. It should not instantiate arbitrary application beans in the operator. If the required configuration cannot be derived consistently from Camel K's declarative model, the Camel community should assess a Camel Core metadata contract that exposes relevant configuration without requiring Camel K to execute the integration. + +This is a design proposal only; it does not introduce a runtime resolver or change the scaler interface. + +== Problem statement + +A KEDA scaler reads metadata to poll an external system and decide when to scale an Integration. Automatic discovery currently starts with a Camel consumer URI, but not every scaler's required metadata is present in that URI. + +Connection information can be configured in several ways, including: + +* endpoint parameters, such as the broker or server option on an endpoint URI; +* component properties, such as `camel.component.<component>.*`; +* named beans configured through Camel properties (for example, `camel.beans.<name>.*`) and referenced from component configuration with `#bean:<name>`; Review Comment: Not implementable (at least in a first iteration): scanning source code to find if a bean is used as connection factory may be complex. ########## proposals/keda-connection-beans.adoc: ########## @@ -0,0 +1,195 @@ +--- +title: Discovering connection configuration for KEDA scalers +authors: + - "@knockknock10" +creation-date: 2026-10-25 +last-updated: 2026-10-25 +status: draft +see-also: + - https://github.com/apache/camel-k/issues/6910 + - https://github.com/apache/camel-k/pull/6893 + - https://github.com/apache/camel-k/issues/6890 +replaces: [] +superseded-by: [] +--- + +[[keda-connection-beans]] += Discovering connection configuration for KEDA scalers + +== Summary + +Camel K can automatically create KEDA triggers from supported consumer endpoint URIs, but a scaler may need connection details configured outside the URI. Those details can live in Camel component properties or in a named bean (for example, a connection factory referenced by a component). The current scaler-mapping contract does not expose a resolved Camel registry or bean configuration to the mapper. + +This proposal recommends keeping automatic discovery static and deterministic. As an initial step, scaler mappings may consume explicit, statically available Integration properties in addition to the endpoint URI. For connection beans, Camel K should first assess a narrowly scoped resolver for declarative property-based bean definitions and references. It should not instantiate arbitrary application beans in the operator. If the required configuration cannot be derived consistently from Camel K's declarative model, the Camel community should assess a Camel Core metadata contract that exposes relevant configuration without requiring Camel K to execute the integration. + +This is a design proposal only; it does not introduce a runtime resolver or change the scaler interface. + +== Problem statement + +A KEDA scaler reads metadata to poll an external system and decide when to scale an Integration. Automatic discovery currently starts with a Camel consumer URI, but not every scaler's required metadata is present in that URI. + +Connection information can be configured in several ways, including: + +* endpoint parameters, such as the broker or server option on an endpoint URI; +* component properties, such as `camel.component.<component>.*`; Review Comment: Implementable: add a section clarify how this can be performed (partially in development in the other PR) ########## proposals/keda-connection-beans.adoc: ########## @@ -0,0 +1,195 @@ +--- +title: Discovering connection configuration for KEDA scalers +authors: + - "@knockknock10" +creation-date: 2026-10-25 +last-updated: 2026-10-25 +status: draft +see-also: + - https://github.com/apache/camel-k/issues/6910 + - https://github.com/apache/camel-k/pull/6893 + - https://github.com/apache/camel-k/issues/6890 +replaces: [] +superseded-by: [] +--- + +[[keda-connection-beans]] += Discovering connection configuration for KEDA scalers + +== Summary + +Camel K can automatically create KEDA triggers from supported consumer endpoint URIs, but a scaler may need connection details configured outside the URI. Those details can live in Camel component properties or in a named bean (for example, a connection factory referenced by a component). The current scaler-mapping contract does not expose a resolved Camel registry or bean configuration to the mapper. + +This proposal recommends keeping automatic discovery static and deterministic. As an initial step, scaler mappings may consume explicit, statically available Integration properties in addition to the endpoint URI. For connection beans, Camel K should first assess a narrowly scoped resolver for declarative property-based bean definitions and references. It should not instantiate arbitrary application beans in the operator. If the required configuration cannot be derived consistently from Camel K's declarative model, the Camel community should assess a Camel Core metadata contract that exposes relevant configuration without requiring Camel K to execute the integration. + +This is a design proposal only; it does not introduce a runtime resolver or change the scaler interface. + +== Problem statement + +A KEDA scaler reads metadata to poll an external system and decide when to scale an Integration. Automatic discovery currently starts with a Camel consumer URI, but not every scaler's required metadata is present in that URI. + +Connection information can be configured in several ways, including: + +* endpoint parameters, such as the broker or server option on an endpoint URI; +* component properties, such as `camel.component.<component>.*`; +* named beans configured through Camel properties (for example, `camel.beans.<name>.*`) and referenced from component configuration with `#bean:<name>`; +* bean definitions in a supported DSL, including definitions that refer to other beans or use factories; and +* property placeholders, environment variables, mounted configuration, or Kubernetes Secrets. + Review Comment: Another missing part that we should analyze: leverage the Pipe, when an Integration is derived from it. We can include a parsing and a mapping of Kamelet properties when the source or sink is a Kamelet. For example, we could retrieve the `broker-url` parameter which may already exist in the Kamelet setting. ########## proposals/keda-connection-beans.adoc: ########## @@ -0,0 +1,195 @@ +--- +title: Discovering connection configuration for KEDA scalers +authors: + - "@knockknock10" +creation-date: 2026-10-25 +last-updated: 2026-10-25 +status: draft +see-also: + - https://github.com/apache/camel-k/issues/6910 + - https://github.com/apache/camel-k/pull/6893 + - https://github.com/apache/camel-k/issues/6890 +replaces: [] +superseded-by: [] +--- + +[[keda-connection-beans]] += Discovering connection configuration for KEDA scalers + +== Summary + +Camel K can automatically create KEDA triggers from supported consumer endpoint URIs, but a scaler may need connection details configured outside the URI. Those details can live in Camel component properties or in a named bean (for example, a connection factory referenced by a component). The current scaler-mapping contract does not expose a resolved Camel registry or bean configuration to the mapper. + +This proposal recommends keeping automatic discovery static and deterministic. As an initial step, scaler mappings may consume explicit, statically available Integration properties in addition to the endpoint URI. For connection beans, Camel K should first assess a narrowly scoped resolver for declarative property-based bean definitions and references. It should not instantiate arbitrary application beans in the operator. If the required configuration cannot be derived consistently from Camel K's declarative model, the Camel community should assess a Camel Core metadata contract that exposes relevant configuration without requiring Camel K to execute the integration. + +This is a design proposal only; it does not introduce a runtime resolver or change the scaler interface. + +== Problem statement + +A KEDA scaler reads metadata to poll an external system and decide when to scale an Integration. Automatic discovery currently starts with a Camel consumer URI, but not every scaler's required metadata is present in that URI. + +Connection information can be configured in several ways, including: + +* endpoint parameters, such as the broker or server option on an endpoint URI; +* component properties, such as `camel.component.<component>.*`; +* named beans configured through Camel properties (for example, `camel.beans.<name>.*`) and referenced from component configuration with `#bean:<name>`; +* bean definitions in a supported DSL, including definitions that refer to other beans or use factories; and Review Comment: Not implementable (at least in a first iteration): scanning source code to find how a connection factory is used. ########## proposals/keda-connection-beans.adoc: ########## @@ -0,0 +1,195 @@ +--- +title: Discovering connection configuration for KEDA scalers +authors: + - "@knockknock10" +creation-date: 2026-10-25 +last-updated: 2026-10-25 +status: draft +see-also: + - https://github.com/apache/camel-k/issues/6910 + - https://github.com/apache/camel-k/pull/6893 + - https://github.com/apache/camel-k/issues/6890 +replaces: [] +superseded-by: [] +--- + +[[keda-connection-beans]] += Discovering connection configuration for KEDA scalers + +== Summary + +Camel K can automatically create KEDA triggers from supported consumer endpoint URIs, but a scaler may need connection details configured outside the URI. Those details can live in Camel component properties or in a named bean (for example, a connection factory referenced by a component). The current scaler-mapping contract does not expose a resolved Camel registry or bean configuration to the mapper. + +This proposal recommends keeping automatic discovery static and deterministic. As an initial step, scaler mappings may consume explicit, statically available Integration properties in addition to the endpoint URI. For connection beans, Camel K should first assess a narrowly scoped resolver for declarative property-based bean definitions and references. It should not instantiate arbitrary application beans in the operator. If the required configuration cannot be derived consistently from Camel K's declarative model, the Camel community should assess a Camel Core metadata contract that exposes relevant configuration without requiring Camel K to execute the integration. + +This is a design proposal only; it does not introduce a runtime resolver or change the scaler interface. + +== Problem statement + +A KEDA scaler reads metadata to poll an external system and decide when to scale an Integration. Automatic discovery currently starts with a Camel consumer URI, but not every scaler's required metadata is present in that URI. + +Connection information can be configured in several ways, including: + +* endpoint parameters, such as the broker or server option on an endpoint URI; +* component properties, such as `camel.component.<component>.*`; +* named beans configured through Camel properties (for example, `camel.beans.<name>.*`) and referenced from component configuration with `#bean:<name>`; +* bean definitions in a supported DSL, including definitions that refer to other beans or use factories; and +* property placeholders, environment variables, mounted configuration, or Kubernetes Secrets. Review Comment: Not implementable: there are many level of indirection. ########## proposals/keda-connection-beans.adoc: ########## @@ -0,0 +1,195 @@ +--- +title: Discovering connection configuration for KEDA scalers +authors: + - "@knockknock10" +creation-date: 2026-10-25 +last-updated: 2026-10-25 +status: draft +see-also: + - https://github.com/apache/camel-k/issues/6910 + - https://github.com/apache/camel-k/pull/6893 + - https://github.com/apache/camel-k/issues/6890 +replaces: [] +superseded-by: [] +--- + +[[keda-connection-beans]] += Discovering connection configuration for KEDA scalers + +== Summary + +Camel K can automatically create KEDA triggers from supported consumer endpoint URIs, but a scaler may need connection details configured outside the URI. Those details can live in Camel component properties or in a named bean (for example, a connection factory referenced by a component). The current scaler-mapping contract does not expose a resolved Camel registry or bean configuration to the mapper. + +This proposal recommends keeping automatic discovery static and deterministic. As an initial step, scaler mappings may consume explicit, statically available Integration properties in addition to the endpoint URI. For connection beans, Camel K should first assess a narrowly scoped resolver for declarative property-based bean definitions and references. It should not instantiate arbitrary application beans in the operator. If the required configuration cannot be derived consistently from Camel K's declarative model, the Camel community should assess a Camel Core metadata contract that exposes relevant configuration without requiring Camel K to execute the integration. + +This is a design proposal only; it does not introduce a runtime resolver or change the scaler interface. + +== Problem statement + +A KEDA scaler reads metadata to poll an external system and decide when to scale an Integration. Automatic discovery currently starts with a Camel consumer URI, but not every scaler's required metadata is present in that URI. + +Connection information can be configured in several ways, including: + +* endpoint parameters, such as the broker or server option on an endpoint URI; Review Comment: Implementable: add a section clarify this already exists and briefly explain the mapping mechanism ########## proposals/keda-connection-beans.adoc: ########## @@ -0,0 +1,195 @@ +--- +title: Discovering connection configuration for KEDA scalers +authors: + - "@knockknock10" +creation-date: 2026-10-25 +last-updated: 2026-10-25 +status: draft +see-also: + - https://github.com/apache/camel-k/issues/6910 + - https://github.com/apache/camel-k/pull/6893 + - https://github.com/apache/camel-k/issues/6890 +replaces: [] +superseded-by: [] +--- + +[[keda-connection-beans]] += Discovering connection configuration for KEDA scalers + +== Summary + +Camel K can automatically create KEDA triggers from supported consumer endpoint URIs, but a scaler may need connection details configured outside the URI. Those details can live in Camel component properties or in a named bean (for example, a connection factory referenced by a component). The current scaler-mapping contract does not expose a resolved Camel registry or bean configuration to the mapper. + +This proposal recommends keeping automatic discovery static and deterministic. As an initial step, scaler mappings may consume explicit, statically available Integration properties in addition to the endpoint URI. For connection beans, Camel K should first assess a narrowly scoped resolver for declarative property-based bean definitions and references. It should not instantiate arbitrary application beans in the operator. If the required configuration cannot be derived consistently from Camel K's declarative model, the Camel community should assess a Camel Core metadata contract that exposes relevant configuration without requiring Camel K to execute the integration. + +This is a design proposal only; it does not introduce a runtime resolver or change the scaler interface. + +== Problem statement + +A KEDA scaler reads metadata to poll an external system and decide when to scale an Integration. Automatic discovery currently starts with a Camel consumer URI, but not every scaler's required metadata is present in that URI. + +Connection information can be configured in several ways, including: + +* endpoint parameters, such as the broker or server option on an endpoint URI; +* component properties, such as `camel.component.<component>.*`; +* named beans configured through Camel properties (for example, `camel.beans.<name>.*`) and referenced from component configuration with `#bean:<name>`; +* bean definitions in a supported DSL, including definitions that refer to other beans or use factories; and +* property placeholders, environment variables, mounted configuration, or Kubernetes Secrets. + +These forms are not equivalent from the operator's perspective. A literal component property may be available while the Integration is being reconciled. A bean reference may point to a property-configured bean, a factory-created object, or a bean supplied by a runtime registry. Some values may be unavailable until the Integration starts, and some cannot safely or reliably be derived from source text alone. + +The goal is to reuse the connection information already declared by a user when it is statically available, without making automatic discovery depend on running application code or guessing at opaque runtime objects. + +== Current implementation and related work + +The current flow is implemented in `pkg/trait/keda.go`, `pkg/metadata/metadata.go`, and `pkg/trait/keda/mapper.go`: + +. The KEDA trait calls `metadata.ExtractAll` on the Integration's sources. Review Comment: I think we can include a section to explain how we can leverage this to also get the component properties. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
