-
Notifications
You must be signed in to change notification settings - Fork 350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Basic example fails on Docker Desktop MacOS #5095
Comments
Thanks for reporting. Can you please verify if the Pod is started and working correctly? or is it the CLI which is failing to scrape the Pod log? |
I see ...
|
It seems the Pod cannot start, likely a registry problem. Have you followed the special instructions required for Docker Desktop? https://camel.apache.org/camel-k/2.2.x/installation/platform/docker-desktop.html |
Yes, I have. The registry is running and camel-k installed with no problem
|
What do you see in the operator logs? |
Please don't hesitate to check the troubleshooting documentation to know what to look for: https://camel.apache.org/camel-k/2.2.x/troubleshooting/troubleshooting.html |
yes, it would be interesting to see what is in the operator logs |
Here you go ...
|
Folks, how would I get started to debug this? |
When running the Camel K operator locally in debug mode on MacOS please make sure to set the environment variable When the wrapper envar is disabled the operator uses the Maven binary that is set in I think this resolves some issues that the integration kit is not being built properly when using a local operator. |
I see the following error message
What does the command returns |
Instead of getting the local operator to get working have you tried to install Camel K on a local Minikube or Kind cluster already? This is my usual way of running Camel K locally with installing the operator on a Minikube cluster as described in https://camel.apache.org/camel-k/2.1.x/installation/platform/minikube.html |
I think the problem is with Kubernetes platform, which is not able to pull the image for some reason. Basically, Camel K is doing his job by building the container image and pushing it to the registry. Then, when the |
works now |
I think we need to reopen this. The basic example
does no longer work an ARM64 without defining additional Is it really the (most common) case, that |
Unfortunately it's a breaking compatibility change. See: #5246 (comment) - mind that what it works for you may be disruptive for another running production environment. |
Testing the upgrade scenarioOn AMD64
Now the upgrade https://camel.apache.org/camel-k/next/contributing/upgrade.html
It seems that the upgrade works fine with
|
More investigation about this in #5292 |
What happened?
https://camel.apache.org/camel-k/2.2.x/running/running.html
The text was updated successfully, but these errors were encountered: