-
Notifications
You must be signed in to change notification settings - Fork 5k
podman-env update from <=3 to 4.9.2+ #21054
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
base: master
Are you sure you want to change the base?
podman-env update from <=3 to 4.9.2+ #21054
Conversation
The committers listed above are authorized under a signed CLA. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: elasticdotventures The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Welcome @elasticdotventures! |
Hi @elasticdotventures. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Can one of the admins verify this patch? |
- Support for Podman v3 and varlink-based communication has been removed. The `podman-env` command now configures your environment to use the Podman REST API socket, as required by Podman v4+. | ||
|
||
{{% pageinfo color="warning" %}} | ||
**Note:** If you are using an older version of Podman, please upgrade to at least v4.9.2 to use `minikube podman-env`. Legacy varlink-based workflows are no longer supported. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The version 4.9.2 is quite specific, it might as well say 4.x (which is not supported anyway) and later (5.x)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use latest podman (5.5) instead of a random old version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think 4.9.3 is random*, but upgrading the client is not an issue.
Some people have problems with downgrading, but that's different.
* it is the "last" common v4 version, just like 1.9.3 was the last v1 version.
We could upgrade to v5, but it is not available in every distribution yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are no features in podman 5 (or even in podman 4, but anyway)
that are required by cri-o, as far as I know? Main issue is client compat.
For the podman driver things are different, there we can require 4.9
This was just for docker-env/podman-env, and what is installed on the VM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you plz post before/after this PR in the description
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should look for podman, or suggest to people to use the podman --remote
client. We should only give a path to a docker socket, for a docker client.
Podman Desktop does not use podman, and Podman Compose does not default to using podman-compose. Instead, they use the Docker API and docker-compose.
Using the podman-remote client, is what is causing these problems with using cri-o.
Error: unable to connect to Podman socket: server API version is too old. Client "4.0.0" server "3.4.4"
It is better to only use docker
as a legacy client, and minikube image
for the rest.
That is why it is called "compatibility socket", while the libpod client/connection keeps breaking the backwards API...
see issue #21052