- Podman - Podman List Archives

Is there any Python module for Podman REST-API ?
by Vivek Satpute 17 Aug '20

17 Aug '20

Hi All, I wish to make use of Podman's REST-APIs in my application. Application will be developed in Python, so is there any Python wrapper interface library available for Podman REST-APIs? I found https://github.com/containers/python-podman module but that uses Podman's Varlink interfaces which I don't want to use as varlink is deprecated. Thanks and Regards, Vivek Satpute

3 2

podman error creating runtime static files
by Seth Kenlon 11 Aug '20

11 Aug '20

On RHEL 8 (CSB), I'm attempting to use podman. I've added myself to /etc/sub{u,g}id, logged out and then back in. I've reinstalled shadow-utils. Everything seems like it ought to work now, but no matter what podman command I run, I seem to hit a runtime error. ``` $ podman --log-level debug image list INFO[0000] running as rootless ERRO[0000] Could not get runtime: error creating runtime static files directory /var/lib/flatpak/exports/share:/containers/storage/libpod: mkdir /var/lib/flatpak/exports/share:: permission denied ``` Running with `sudo` is successful, but I'm trying to avoid a `sudo` dependency if possible. Ultimately, I'd like to pull an image from quay.io via the podman Ansible module, and I assume this error is why my playbook reliably fails at the podman task.

3 7

CI Fails trying to upload artifacts: EOF
by Chris Evich 03 Aug '20

03 Aug '20

Hey all, Casting a wide-net here because the problem is infrequent :S In the course of hacking on podman or any other containers project, in the next week or so (ending Aug 21st): Please let me know if you notice a CI failure such as: "Failed to upload artifact file /blah/blah/blah: EOF" For example: https://cirrus-ci.com/task/5071485364600832 https://cirrus-ci.com/task/5339766201778176 https://cirrus-ci.com/task/5621241178488832 The (fantastic) support @ Cirrus-CI has some additional logging in place to try and help debug this issue. I need to feed them failure URLs to help speed the search. Thanks in advance! -- Chris Evich, RHCA III Senior Quality Assurance Engineer If it ain't broke, yain't tryin' hard nough.

1 0

Podman API v1.0 Deprecation and Removal Notice
by Tom Sweeney 01 Aug '20

01 Aug '20

The Podman v1.0 API relied on the varlink library (https://github.com/varlink/libvarlink) to handle the underlying client/server calls from the Podman client to the host where the Podman service was running. About one year ago, the Podman team was notified that the varlink library was being deprecated and there would be no further development and little support for it from the varlink library team. This led the Podman team to investigate the use of other client/server technologies and it was decided to develop a RESTful API for Podman using the native Go libraries. This new Podman v2.0 RESTful API was released along with Podman v2.0 in June of 2020 and replaces the Podman API v1.0. As of that time the Podman v1.0 API for Podman is considered to be deprecated. If there are issues with the Podman v1.0 API in versions of Podman prior to v2.0 and those versions are still under support on Red Hat Enterprise Linux (RHEL), the Podman team will make a best effort to address those issues. However, no new feature requests for the v1.0 API will be considered and any problems found with the v1.0 API in Podman v2.0 will not be addressed. The new Podman v2.0 RESTful API is split into two halves: one providing a Docker-compatible API, and a Libpod API providing support for Podman’s unique features such as pods. The new API works in both a rootful and a rootless environment. It is a much more flexible solution and Podman will not have a dependency on another project in order to supply an API. For more information on the Podman v2.0 RESTful API please see articles on the podman.io site (https://podman.io/) and also the documentation for the Podman v2.0 RESTful API (http://docs.podman.io/en/latest/Reference.html) Distributions have to support services for the length of their support agreements. The Podman development team wants to be free to update the version of Podman during this support cycle. Therefore, we are planning to drop support for Podman API v1.0 from distributions Red Hats is the packagers for. The version of Podman, 2.*, which is contained in Fedora 33, scheduled to be released around Oct 31, 2020, will ship with no varlink support. We also plan to drop support from the RHEL8.4 release, spring 2021. Other distributions like OpenSUSE have already disabled varlink support and we have heard that other distributions will follow suit. This also serves as a notification that the Podman v1.0 (varlink) API will be removed from the main GitHub branch of Podman in the near future. With the release of Podman v2.0 the Podman developers deprecated the Podman v1.0 API in favor of the new Podman v2.0 RESTful API. The plan is to remove varlink completely from the Podman v3.0 development branch which will be created some time after September 2020. A 30 day notification of the final removal date will be posted on the https://podman.iosite and also on the Podman mailing list, along with social media once it is definitively determined. If you have any questions or concerns about this notification, please send a note to the Podman mailing list or create an issue on Podman’s GitHub (https://github.com/containers/podman/issues) repository. Note: This notice will be posted to the podman.io site early next week.

2 2

New version of podman available
by Daniel Walsh 27 Jul '20

27 Jul '20

Mainly bugfix release. Please try this out. Please try this out. We would like to know if there are any issues, before it gets released to your favorite distributions. v2.0.3 <https://github.com/containers/podman/releases/tag/v2.0.3> @mheon <https://github.com/mheon> mheon <https://github.com/mheon> released this 16 hours ago · 364 commits <https://github.com/containers/podman/compare/v2.0.3...master> to master since this release Features * The |podman search| command now allows wildcards in search terms. * The |podman play kube| command now supports the |IfNotPresent| pull type. Changes * The |--disable-content-trust| flag has been added to Podman for Docker compatibility. This is a Docker-specific option and has no effect in Podman; it is provided only to ensure command line compatibility for scripts (#7034 <https://github.com/containers/podman/issues/7034>). * Setting a static IP address or MAC address for rootless containers and pods now causes an error; previously, they were silently ignored. * The |/sys/dev| folder is now masked in containers to prevent a potential information leak from the host. Bugfixes * Fixed a bug where rootless Podman would select the wrong cgroup manager on cgroups v1 systems where the user in question had an active systemd user session (#6982 <https://github.com/containers/podman/issues/6982>). * Fixed a bug where systems with Apparmor could not run privileged containers (#6933 <https://github.com/containers/podman/issues/6933>). * Fixed a bug where ENTRYPOINT and CMD from images were improperly handled by |podman play kube| (#6995 <https://github.com/containers/podman/issues/6995>). * Fixed a bug where the |--pids-limit| flag to |podman create| and |podman run| was parsed incorrectly and was unusable (#6908 <https://github.com/containers/podman/issues/6908>). * Fixed a bug where the |podman system df| command would error if untagged images were present (#7015 <https://github.com/containers/podman/issues/7015>). * Fixed a bug where the |podman images| command would display incorrect tags if a port number was included in the repository. * Fixed a bug where Podman did not set a default umask and default rlimits (#6989 <https://github.com/containers/podman/issues/6989>). * Fixed a bug where protocols in port mappings were not recognized unless they were lower-case (#6948 <https://github.com/containers/podman/issues/6948>). * Fixed a bug where information on pod infra containers was not included in the output of |podman pod inspect|. * Fixed a bug where Podman's systemd detection (activated by the enabled-by-default |--systemd=true| flag) would not flag a container for systemd mode if systemd was part of the entrypoint, not the command (#6920 <https://github.com/containers/podman/issues/6920>). * Fixed a bug where |podman start --attach| was not defaulting |--sig-proxy| to true (#6928 <https://github.com/containers/podman/issues/6928>). * Fixed a bug where |podman inspect| would show an incorrect command (|podman system service|, the command used to start the server) for containers created by a remote Podman client. * Fixed a bug where the |podman exec| command with the remote client would not print output if the |-t| or |-i| flags where not provided. * Fixed a bug where some variations of the |--format {{ json . }}| to |podman info| (involving added or removed whitespace) would not be accepted (#6927 <https://github.com/containers/podman/issues/6927>). * Fixed a bug where Entrypoint could not be cleared at the command line (if unset via |--entrypoint=""|, it would be reset to the image's entrypoint) (#6935 <https://github.com/containers/podman/issues/6935>). API * Fixed a bug where the events endpoints (both libpod and compat) could potentially panic on parsing filters. * Fixed a bug where the compat Create endpoint for containers did not properly handle Entrypoint and Command. * Fixed a bug where the Logs endpoint for containers (both libpod and compat) would not properly handle client disconnect, resulting in high CPU usage. * The type of filters on the compat events endpoint has been adjusted to match Docker's implementation (#6899 <https://github.com/containers/podman/issues/6899>). * The idle connection counter now properly handles hijacked connections. * All endpoints that hijack will now properly print headers per RFC 7230 standards. Misc * Updated containers/common to v0.14.6

3 2

Anyone on this list from jfrog/artifactory or know of anyone
by Daniel Walsh 22 Jul '20

22 Jul '20

We seem to have an issue with Podman working with Artifactory that we would like to work through with their engineering team. https://github.com/containers/podman/issues/4254 Would love to have a contact name.

2 1

connecting a container to a bridge network and the host network
by Hendrik Haddorp 21 Jul '20

21 Jul '20

Hi, is it possible to connect a container to a bridge network and also to the host network? I would like for my container to have full access to the hosts network interfaces but still have an IP in the normal bridge network so that other containers can communicate with it normally. thanks, Hendrik

3 4

podman --version 2.0.2 is released
by Daniel Walsh 08 Jul '20

08 Jul '20

We would appreciate people playing with and testing it. We are trying to fix as many small bugs as possible, as quick as possible. Since Podman 2.0 was a major rewrite of the CLI, we are seeing some issues especially around corner cases. Thanks for helping out the community.

1 0

The Podman repository has been renamed
by Daniel Walsh 08 Jul '20

08 Jul '20

The Podman repository has been renamed By Matt Heon GitHub <https://github.com/mheon> The Podman <https://podman.io/> repository on Github is moving from github.com/containers/libpod <https://github.com/containers/libpod> to github.com/containers/podman <https://github.com/containers/podman>! Read on to find out why, and how it will affect you. Three years ago, we created a new Git repository to hold our new container-management tool and the library it was based on. At the time, Podman was not named Podman, but |kpod| - a name no one on the team liked, and one we’d hoped to replace quickly. Given this, we decided to name the repository after the library we’d written to manage containers - |libpod|. Four months after that, we made the first public release of the tool, and with it came a new name - Podman (POD MANager). The rest is, as they say, history. The Podman team is incredibly grateful for the success we’ve seen since then, and the way that the community has grown. ... https://podman.io/blogs/2020/07/07/repo-rename.html

1 0

Supported versions of golang for building Podman.
by Daniel Walsh 08 Jul '20

08 Jul '20

We are going through a rough transition right now, with us dropping support for golang 1.12. This is causing some pain in Ubuntu and Debian communities. The issues is some of the code we vendor from other projects has added requirements that only work on golang 1.13 and beyond. Currently the stable branch of golang is 1.14 and 1.13. Valentin Rothberg reports to me. > Good news is that we are lucky: Debian testing and unstable are both > on Go 1.14 (https://packages.debian.org/search?keywords=golang) He suggests: > a policy that our tools (at new release) must be compatible with the > officially supported versions of Go, which is always the last two > major/minor versions. In case of Podman 2.0: 1.14 and 1.13. If we can > commit to that, the community can't really get angry at us; it's > reasonable to move on once a version hits EOL. However, breaking > changes are always an annoyance ... I agree with this suggestion. And think this is the way we should go forward. We are also working to make sure we can build on Ununtu LTS. RHEL and Centos already can use the golang 1.13 compilers.

1 0