Builder trait maven-profiles expect the profile in the operator namespace

[gansheer]

What happened?

When working with the following topology:

• a global operator
• an integration in a namespace different than the one where the Camel K operator pod is installed using a maven profile from a configmap/secret defined in the integration namespace
  the build is in error because it expects to find the configmap/secret containing the maven profile in the namespace where the operator is deployed.

In a way it make sense that this behavior is applied since the maven-profile is a build parameter and the build is done by the Camel K operator. At the same time, in theory, when a user creates its own integration he should not need to access the operator namespace.

Which brings the real issue: shoud the user be able to build a Camel K Integration project defining its own maven profile and declare it or should we expect the build parameters to only use maven-profiles pre-created?

Note: This issue is also valid for this feature : #4639

Steps to reproduce

1. Install the Camel K operator as global: kamel install --global -n camel-k
2. Create a user namespace: kubectl create namespace user1
3. Create a configmap containing a profile in the user namespace: kubectl create configmap maven-profile-dependency --from-file=[path]/dependency-profile.xml -n user1
4. Run an integration in the user namespace: kamel run Test.java -t builder.maven-profiles=configmap:maven-profile-dependency/dependency-profile.xml -n user1

Relevant log output

amel-k-operator-d4bc654cc-8cj25 camel-k-operator {"level":"info","ts":"2024-04-15T13:42:08Z","logger":"camel-k.controller.build","msg":"Build duration 301.071971ms","request-namespace":"user1","request-name":"test","build-attempt":0,"build-result":"Failed","build-duration":0.301071971,"api-version":"camel.apache.org/v1","kind":"Build","ns":"camel-k","name":"kit-coeitc77nc44koqlsgn0"}
camel-k-operator-d4bc654cc-8cj25 camel-k-operator {"level":"error","ts":"2024-04-15T13:42:08Z","logger":"camel-k.controller.build","msg":"Build kit-coeitc77nc44koqlsgn0 failed: could not load profile : configmap:maven-profile-dependency/dependency-profile.xml: ConfigMap \"maven-profile-dependency\" not found. ","request-namespace":"camel-k","request-name":"kit-coeitc77nc44koqlsgn0","api-version":"camel.apache.org/v1","kind":"Build","ns":"camel-k","name":"kit-coeitc77nc44koqlsgn0","stacktrace":"github.com/apache/camel-k/v2/pkg/util/log.Logger.Errorf\n\tgithub.com/apache/camel-k/v2/pkg/util/log/log.go:66\ngithub.com/apache/camel-k/v2/pkg/controller/build.(*monitorRoutineAction).updateBuildStatus\n\tgithub.com/apache/camel-k/v2/pkg/controller/build/monitor_routine.go:216\ngithub.com/apache/camel-k/v2/pkg/controller/build.(*monitorRoutineAction).runBuild\n\tgithub.com/apache/camel-k/v2/pkg/controller/build/monitor_routine.go:200"}

Camel K version

main, 2.3.x

[claudio4j]

shoud the user be able to build a Camel K Integration project defining its own maven profile

Yes, as the there is the user scoped -t builder.maven-profiles parameter, then definitely the global operator should read the maven profile in user1 ns.

[squakez]

Could the feature only work for namespaced operator? We can add a check on the builder trait and warn the user that the option would not take effect as the Integration is operated by a global operator. Or is this feature also used internally by the operator by any chance?

[gansheer]

The feature is used for the Jib publish startegy. A configmap containing the JIB profile is created in the operator namespace. This configmap is owned by the IntegrationKit.
In the builder trait code there is not a lot of information on the Integration, this build configuration/paramaters concerns the IntegrationKit so it makes sense.

Could the feature only work for namespaced operator? We can add a check on the builder trait and warn the user that the option would not take effect as the Integration is operated by a global operator.

If the configmap is created in the operator namespace, it actually works.

[squakez]

Okey, then, if IIUC this problem is not affecting the general build, but only a build where we expect a profile provided by the user. As you correctly said, the profile is meant to be a configuration of the IntegrationKit, hence, it's natural place is the IntegrationKit namespace. I think this particular situation should be only documented as available providing the configmap in the namespace where the operator is going to create the IntegrationKit (if it would change in the future) if the user really needs it. It is reported correctly in conditions, so it is quite clear the reason why this is failing:

      message: 'integration kit global/kit-cojsajgpro1c738mvbh0 is in state "Error".
        Failure: could not load profile : configmap:my-profile/profile.xml: ConfigMap
        "my-profile" not found. '