Re: [I] Pod failure when using fixed native image [camel-k]

2024-04-19 Thread via GitHub


hernanDatgDev closed issue #5207: Pod failure when using fixed native image
URL: https://github.com/apache/camel-k/issues/5207


-- 
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: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [I] Pod failure when using fixed native image [camel-k]

2024-03-04 Thread via GitHub


gansheer commented on issue #5207:
URL: https://github.com/apache/camel-k/issues/5207#issuecomment-1976832191

   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 :
   ```yaml
   containers:
 - name: integration
   command:
 - ./camel-k-integration-2.3.0-SNAPSHOT-runner
   workingDir: /deployments
   ```
   Using the kamel CLI it would be : `kamel run --image=x --name external  
--pod-template patch_pod.yaml`
   
   We are back in the issue discussed 
[here](https://github.com/apache/camel-k/issues/5112#issuecomment-1930342054) 
about the necessity to create 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.


-- 
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: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [I] Pod failure when using fixed native image [camel-k]

2024-03-04 Thread via GitHub


gansheer commented on issue #5207:
URL: https://github.com/apache/camel-k/issues/5207#issuecomment-1976523731

   @squakez I'll look into this issue.


-- 
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: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[I] Pod failure when using fixed native image [camel-k]

2024-03-01 Thread via GitHub


hernanDatgDev opened a new issue, #5207:
URL: https://github.com/apache/camel-k/issues/5207

   ### 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)


-- 
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: commits-unsubscr...@camel.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org