squakez commented on issue #5924:
URL: https://github.com/apache/camel-k/issues/5924#issuecomment-2466089293
I managed to reproduce the issue. It seems to be a regression on mount trait:
```
Warning FailedMount 59s (x8 over 2m3s) kubelet
MountVolume.SetUp failed for volum
squakez commented on issue #5924:
URL: https://github.com/apache/camel-k/issues/5924#issuecomment-2463891978
Thanks for the reproducer. I'll try that out. I wonder if this specific
endpoint (`health`) is conflicting with the normal `health` endpoint we're
providing.
--
This is an automat
hernanDatgDev commented on issue #5924:
URL: https://github.com/apache/camel-k/issues/5924#issuecomment-2463315268
Here is the basic groovy example I'm using (I originally used Java):
open-api-test.groovy:
```
// camel-k: trait=openapi.configmaps=basic-health-api
// camel-k: t
hernanDatgDev commented on issue #5924:
URL: https://github.com/apache/camel-k/issues/5924#issuecomment-2463033022
The strange part is that there is no explicit error however the integration
pod fails to actually start. It's in a perpetual "Container starting" state.
I've tried with v2.5.0
squakez commented on issue #5924:
URL: https://github.com/apache/camel-k/issues/5924#issuecomment-2462847910
I've done some test and I wasn't able to reproduce any error. Both with
plain Deployment and with KnativeService, I can run the application with
openapi trait normally. A question th
squakez commented on issue #5924:
URL: https://github.com/apache/camel-k/issues/5924#issuecomment-2458872178
Hello, thanks for reporting. The order should not matter. I will have a look
later in the day to see what could be the root cause of this failure. Would you
mind to run the same with
hernan-abi opened a new issue, #5924:
URL: https://github.com/apache/camel-k/issues/5924
### What happened?
Using the open-api trait succeeds in v2.4.x and fails in 2.5.0 with the same
configuration/integration.
I'm using a very basic open-api spec and integration. Basically a
