feat(catalog): capabilities properties

[squakez]

With this PR we enrich the catalog and let certain runtime aspects to be managed via properties (with something similar to this draft [1]). Together with a work on the operator, we'll be able to simplify the management of runtimes and offload the specific runtime aspects, being able to delegate this to the runtime directly. The result of this PR will enrich 3.8.0 future catalog as following:

      health:
        dependencies:
        - groupId: org.apache.camel.quarkus
          artifactId: camel-quarkus-microprofile-health
        metadata:
        - key: defaultLivenessProbePath
          value: /q/health/live
        - key: defaultReadinessProbePath
          value: /q/health/ready
        - key: defaultStartupProbePath
          value: /q/health/started
...
      logging:
        runtimeProperties:
        - key: color
          value: quarkus.console.color
        - key: format
          value: quarkus.log.console.format
        - key: json
          value: quarkus.log.console.json
        - key: jsonPrettyPrint
          value: quarkus.log.console.json.pretty-print
        - key: level
          value: quarkus.log.level
...
      master:
        dependencies:
        - groupId: org.apache.camel.k
          artifactId: camel-k-master
        runtimeProperties:
        - key: labelKeyFormat
          value: quarkus.camel.cluster.kubernetes.labels."%s"
        - key: resourceName
          value: quarkus.camel.cluster.kubernetes.resource-name
        - key: resourceType
          value: quarkus.camel.cluster.kubernetes.resource-type
        buildTimeProperties:
        - key: enabled
          value: quarkus.camel.cluster.kubernetes.enabled
...
      telemetry:
        dependencies:
        - groupId: org.apache.camel.quarkus
          artifactId: camel-quarkus-opentelemetry
        runtimeProperties:
        - key: endpoint
          value: quarkus.opentelemetry.tracer.exporter.otlp.endpoint
        - key: sampler
          value: quarkus.opentelemetry.tracer.sampler
        - key: samplerParentBased
          value: quarkus.opentelemetry.tracer.sampler.parent-based
        - key: samplerRatio
          value: quarkus.opentelemetry.tracer.sampler.ratio
        - key: serviceName
          value: quarkus.opentelemetry.tracer.resource-attributes

Eventually any other runtime (ie Springboot) should be adding the specific capabilities accordingly and it would be transparent for the operator.

[1] apache/camel-k#5251

Release Note

feat(catalog): capabilities properties

[lburgazzoli]

it would be nice to validate if i.e. the same keys also apply to spring-boot

[squakez]

Correct. I think this would be the next step when we onboard the new runtime. We'd need to understand how to harmonize the parameters expected by the operator according to the different runtimes requirements. The goal of this PR is to move towards that goal without breaking compatibility of what's expected now. Eventually it will be a matter of changing these parameters in the future catalog releases, driven by the changes in the operator as well.

[lburgazzoli]

I guess there are many more questions that must be answered, i.e. :

• how to handle cases where a key is not applicable, but another one is needed
• how to handle breaking changes, so properties that have disappeared or become required ('d like to avoid having to do version checks)

[squakez]

I acknowledge them but this PR doesn't aim to solve this aspect. This is something we need to address regardless this PR. Do you think that challenge can be tackled separately?

[lburgazzoli]

I don't see a json logging option in spring-boot https://docs.spring.io/spring-boot/docs/3.0.0/reference/htmlsingle/#features.logging, it seems that to enable json logging one has to use a backend specific logging configuration

[squakez]

Correct. Same comment as with the above telemetry capability.

[squakez]

@lburgazzoli I've addressed the metadata properties. As mentioned for the other concern, although it's valid I think it is not relevant to this PR and will have to be solved regardless of this. Let me know if you have any objection to merge, so I can start the related work on the operator side.

[claudio4j]

Is it planned to backport to 3.2.x / 3.6.x for backward compatibility ?

[claudio4j]

This idea in general is good as the description says, so +1.

[squakez]

Is it planned to backport to 3.2.x / 3.6.x for backward compatibility ?

No. The compatibility will be managed at runtime, ie, 3.2 runtime mechanism will work in its own way, according to its spec. The operator will still have to handle (and deprecated as illustrated in https://github.com/apache/camel-k/pull/5251/files#diff-22dc2842d3dc75fd50c5856a16c240e8c17dc3f9785d8ab14dc6eb6a990134beR70) also the older approach which will eventually disappear after deprecation policy has expired.