Pod failure when using fixed native image

[hernanDatgDev]

What happened?

Link to Zulip chat: https://camel.zulipchat.com/#narrow/stream/257299-camel-k/topic/Run.20integration.20w.20existing.20native.20image.20.2F.20image.20trait

When running an integration with a native image defined explicitly the pod is using the wrong command to start the container and as a result the pod fails to start. Under normal native integration execution (without defining the container image) the pod is started with a command that calls the native executable. For example:

- command:
   - ./camel-k-integration-2.3.0-runner

When running an integration in the default jvm mode, the pod command is different. For example

- args:
     ...
     io.quarkus.bootstrap.runner.QuarkusEntryPoint
   command:
   - /bin/sh
   - -c

When running an integration with a native image defined explicitly, the pod tries to start the native app with the default jvm command which does not work. With guidance from the community I tried running the same integration with the native image, also with the JVM trait disabled. This resulted in the pod having no command defined at all, which of course did still not work. There was a brief mention in Zulip for including the starting command to the kit image itself. I personally favor this suggestion however looking for further guidance on the best way to move forward with this issue.

Steps to reproduce

1. Run any integration in native mode. Save the image generated.
2. Run any other integration (can be the same), and configure the container.image trait with the image saved from step 1.

Relevant log output

No response

Camel K version

2.3.0-SNAPSHOT, 2.1.0 (personal patched version)

[gansheer]

@squakez I'll look into this issue.

[gansheer]

As far as execution goes it works as it should.

By adding the container.image trait you are creating a external integration kit. As such the jvm trait is disabled.
Also, the jvm trait is disabled by default for native build case.
A workaround to have the run work as you expect is to run your image as a source less integration and add the following pod template :

containers:
  - name: integration
    command:
      - ./camel-k-integration-2.3.0-SNAPSHOT-runner
    workingDir: /deployments

Using the kamel CLI it would be : kamel run --image=xxxxx --name external --pod-template patch_pod.yaml

We are back to the issue discussed here about the necessity to have the integration kit as well as the container image in the case we want to reuse one created by the operator. As for now most of the command configuration is described the integrationkit : the artifacts, the type of layout (that will define if it is native or not), etc.