Traits in kamel-config.yaml are ignored if a trait is present as a modeline or as a command parameter

[petolexa]

Dear camelk-k developers.

when creating camel-k projects, we try to keep as much configuration as possible in the kamel-config.yaml. Including traits, like in this example:

kamel:
  run:
    integration:
      conftest:
        annotations:
        - prometheus.io/path=/q/metrics
        - prometheus.io/port=8080
        - prometheus.io/scrape=true
        build-properties: []
        configs: []
        connects: []
        dependencies:
        - mvn:io.quarkus:quarkus-security
        - mvn:io.quarkus:quarkus-elytron-security-properties-file
        - mvn:io.quarkus:quarkus-elytron-security-ldap
        envs:
        - QUARKUS_PROFILE=dev
        labels: []
        maven-repositories: []
        open-apis: []
        properties: []
        resources:
        - file:resources/truststore.jks
        sources: []
        traits:
        - jvm.options=-Djavax.net.ssl.trustStore=/etc/camel/resources/truststore.jks
        - jvm.options=-Djavax.net.ssl.trustStorePassword=password
        - openapi.enabled=true
        - logging.enabled=true
        - knative-service.enabled=true
        - knative-service.min-scale=1
        - knative-service.max-scale=2
        volumes: []

If there's no trait added in Modeline in source code AND no trait added as a parameter of kamel run, the integraion runs well. But if any of above mentioned is added, all the traits from kamel-config.yaml are ignored. Just traits - properties from e.g. property files are added successfully.

For example, this is the proper kamel run -o yaml output, where only kamel-config.file traits are used:

apiVersion: camel.apache.org/v1
kind: Integration
metadata:
  annotations:
    prometheus.io/path: /q/metrics
    prometheus.io/port: "8080"
    prometheus.io/scrape: "true"
  creationTimestamp: null
  name: conftest
  namespace: ps-idp
spec:
  dependencies:
  - mvn:io.quarkus:quarkus-security
  - mvn:io.quarkus:quarkus-elytron-security-properties-file
  - mvn:io.quarkus:quarkus-elytron-security-ldap
  sources:
  - content: |
      // camel-k: language=java


      import org.apache.camel.builder.RouteBuilder;

      public class conftest extends RouteBuilder {
        @Override
        public void configure() throws Exception {

            // Write your routes here, for example:
            from("timer:java?period=1000")
              .routeId("java")
              .setBody()
                .simple("Hello Camel K from ${routeId}")
              .to("log:info");

        }
      }
    name: conftest.java
  traits:
    environment:
      configuration:
        vars:
        - QUARKUS_PROFILE=dev
    jvm:
      configuration:
        options:
        - -Djavax.net.ssl.trustStore=/etc/camel/resources/truststore.jks
        - -Djavax.net.ssl.trustStorePassword=password
    knative-service:
      configuration:
        enabled: true
        maxScale: 2
        minScale: 1
    logging:
      configuration:
        enabled: true
    mount:
      configuration:
        resources:
        - configmap:cm-ae7091cde5105c62d22275256156c06848d74d21/truststore.jks@/etc/camel/resources/truststore.jks
    openapi:
      configuration:
        enabled: true
status: {}

If I add following modeline to the code: // camel-k: trait=jvm.options=-Djavax.net.ssl.debug=all this is the result output yaml (kamel-config.yaml is still present in the project, just traits are ignored):

apiVersion: camel.apache.org/v1
kind: Integration
metadata:
  annotations:
    prometheus.io/path: /q/metrics
    prometheus.io/port: "8080"
    prometheus.io/scrape: "true"
  creationTimestamp: null
  name: conftest
  namespace: ps-idp
spec:
  dependencies:
  - mvn:io.quarkus:quarkus-security
  - mvn:io.quarkus:quarkus-elytron-security-properties-file
  - mvn:io.quarkus:quarkus-elytron-security-ldap
  sources:
  - content: |
      // camel-k: language=java

      // camel-k: trait=jvm.options=-Djavax.net.ssl.debug=all

      import org.apache.camel.builder.RouteBuilder;

      public class conftest extends RouteBuilder {
        @Override
        public void configure() throws Exception {

            // Write your routes here, for example:
            from("timer:java?period=1000")
              .routeId("java")
              .setBody()
                .simple("Hello Camel K from ${routeId}")
              .to("log:info");

        }
      }
    name: conftest.java
  traits:
    environment:
      configuration:
        vars:
        - QUARKUS_PROFILE=dev
    jvm:
      configuration:
        options:
        - -Djavax.net.ssl.debug=all
    mount:
      configuration:
        resources:
        - configmap:cm-ae7091cde5105c62d22275256156c06848d74d21/truststore.jks@/etc/camel/resources/truststore.jks
status: {}

So I am missing all the traits from the kamle-config.yaml:

        - jvm.options=-Djavax.net.ssl.trustStore=/etc/camel/resources/truststore.jks
        - jvm.options=-Djavax.net.ssl.trustStorePassword=password
        - openapi.enabled=true
        - logging.enabled=true
        - knative-service.enabled=true
        - knative-service.min-scale=1
        - knative-service.max-scale=2

This is only issue in combination with kamel-config.yaml file. If I only use trait in Modeline together with trait as a command parameter, both traits are used properly.

Could you please check and possibly fix?

[tadayosi]

It should be related to how the flags decoding is implemented: https://github.com/apache/camel-k/blob/main/pkg/cmd/run.go#L176-L236

[petolexa]

Thank you for your response and code link. If I understand correctly, there are two iterations:

1. flags from Modeline and/or command parameter.
2. flags from kamel-config.yaml

1st iteration is superior and if any of the flags contains data on 1st iteration, data from the 2nd iteration for that specific flag are ignored, not combined, right? So we have to count on it during integration development and either strictly use the way nr.1 or strictly use the way nr.2 for each flag, right?

Is this a feature - because of the hack you pointed me on, or can this be considered as a bug?

[tadayosi]

Yes, for now it is right. I think it's a bug which should be fixed.

[petolexa]

Thank you for your confirmation and a bug label.

[squakez]

I think we cannot do much more on the CLI. Also, considering we are willing to move to Camel Jbang CLI, we instead favour user profiles #934 development.