Skip to content
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

Error running commands when using platform=podman #7252

Closed
jeffgus opened this issue Jun 19, 2024 · 10 comments · Fixed by #7269
Closed

Error running commands when using platform=podman #7252

jeffgus opened this issue Jun 19, 2024 · 10 comments · Fixed by #7269
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/active Indicates that an issue or PR is actively being worked on. It will not be closed automatically.

Comments

@jeffgus
Copy link

jeffgus commented Jun 19, 2024

/kind bug

What versions of software are you using?

Operating System:
Fedora 40

Output of odo version:
odo v3.15.0 (10b5e8a)
also tried:
odo v3.16.1 (cd346c5-nightly)

How did you run odo exactly?

odo dev --platform=podman

Actual behavior

The pods startup in podman, but commands fail. I also get this error during startup:

✗ Building your application in container (command: install) [436ms]
Error occurred on Push - unable to log error unable to exec command [/bin/sh -c cd ${PROJECT_SOURCE} && (npm install) 1>>/proc/1/fd/1 2>>/proc/1/fd/2]: exit status 254: a running component clientapp doesn't exist on the cluster: json: cannot unmarshal array into Go value of type podman.PodInspectData

Expected behavior

odo startup should start podman pods without errors. Issuing odo run <command> should also work.

Any logs, error output, etc?

✗ Building your application in container (command: install) [436ms]
Error occurred on Push - unable to log error unable to exec command [/bin/sh -c cd ${PROJECT_SOURCE} && (npm install) 1>>/proc/1/fd/1 2>>/proc/1/fd/2]: exit status 254: a running component clientapp doesn't exist on the cluster: json: cannot unmarshal array into Go value of type podman.PodInspectData

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Jun 19, 2024
@github-actions github-actions bot added the needs-triage Indicates an issue or PR lacks a `triage/*` and requires one. label Jun 19, 2024
@jeffgus
Copy link
Author

jeffgus commented Jun 19, 2024

I re-cloned the tree into a new dir. The start now works, but odo run is still failing.

Some files must have biffed up the initial sync.

@rm3l
Copy link
Member

rm3l commented Jun 19, 2024

Thanks for reporting this issue, @jeffgus ! Would you mind sharing the output of odo version (to check the version of Podman)?
Also, the output of odo dev --platform=podman -v=9 please.
I suspect odo may no longer work with the newest versions of Podman..

@jeffgus
Copy link
Author

jeffgus commented Jun 19, 2024

I think you're right. Fedora 40 is using podman 5.1.1.

I also noticed that odo logs --follow --platform podman is not working. It doesn't kick out an error, it just sits there without any output.

odo v3.16.1 (cd346c5e6-nightly)

Server: https://xxxxxxxxxxxxxxxx:6443
OpenShift: 4.14.27
Kubernetes: v1.27.13+048520e
Podman Client: 5.1.1

I also tried with odo 3.15.0

The -v=9 produced A LOT of output. I'll make a simple devfile.yaml and get the output instead of the one I'm using which is more complicated.

Copy link
Contributor

A friendly reminder that this issue had no activity for 90 days. Stale issues will be closed after an additional 30 days of inactivity.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 18, 2024
@too-common-name
Copy link
Contributor

Hi guys,
I have the same problem I think. My environment:

OS: Fedora 40
odo v3.16.1 (v3.16.1)
Podman Client: 5.2.3

I am able to run: odo dev --platform podman and all works fine. Once the pod is up and running if I execute:
odo run debug --platform podman
odo logs --platform podman
I got errors.
I think the problem is related to this PR: from several months the command podman pod inspect ... returns a json array instead a json object. I handle this case in a fork of odo, you can find it here. What do you think?

@rm3l
Copy link
Member

rm3l commented Oct 9, 2024

Thanks @too-common-name for looking into this. Indeed, odo relies on the output of podman pod inspect, and it seems its output was changed in Podman 5+.
Would you mind contributing your changes back as a pull request here?
Thanks.

@rm3l rm3l removed the needs-triage Indicates an issue or PR lacks a `triage/*` and requires one. label Oct 9, 2024
@rm3l
Copy link
Member

rm3l commented Oct 9, 2024

/lifecycle active

@openshift-ci openshift-ci bot added lifecycle/active Indicates that an issue or PR is actively being worked on. It will not be closed automatically. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Oct 9, 2024
@too-common-name
Copy link
Contributor

Hi @rm3l,
I checked the pipeline results and fixed the variable shadowing issue. However, I’m not sure which integration tests are failing. When I run the tests locally, I get the following error:
[odo] ✗ unable to access podman. Do you have podman client installed and configured correctly? cause: exit status 125
Despite this, odo version correctly shows the Podman version, and I can run Podman commands without issues. Any guidance on troubleshooting this would be appreciated.

@rm3l
Copy link
Member

rm3l commented Oct 11, 2024

Hi @rm3l, I checked the pipeline results and fixed the variable shadowing issue. However, I’m not sure which integration tests are failing. When I run the tests locally, I get the following error: [odo] ✗ unable to access podman. Do you have podman client installed and configured correctly? cause: exit status 125 Despite this, odo version correctly shows the Podman version, and I can run Podman commands without issues.

What's the Podman version displayed by odo version?

Any guidance on troubleshooting this would be appreciated.

I think this is because of a breaking change in Podman. IIRC, the current integration tests on Podman rely on a namespacing feature in Podman, but which got dropped in Podman v4.5.0: containers/podman@c4fe0af (#17586)
I guess you have a recent version of Podman. If so, you can set the PODMAN_USE_NAMESPACES env var to false prior to starting the tests..

@too-common-name
Copy link
Contributor

Hi @rm3l, I confirm the problem is the one you spotted. I looked a bit inside the code and found the variable: setting PODMAN_USE_NAMESPACES to false tests run. I also incremented a bit the maximum number of open file descriptors as I had errors related to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/active Indicates that an issue or PR is actively being worked on. It will not be closed automatically.
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants