May 2021 - Podman - Podman List Archives

podman and kubernetes
by Thierry Parmentelat 26 May '21

26 May '21

Hello podman I recently came across a message on the kubernetes discourse here https://discuss.kubernetes.io/t/getting-kubernetes-to-work-with-podman-3-1-… and I thought it would make sense to chime in here in essence in that post we share our surprise to see so little reference to podman in the k8s documentation as a first step imho it would drastically help to at least know what combinations of fedora/k8s/cri-o are expected to work properly on my side I’ve just started playing with this combo: * plain fedora33 * with its vanilla podman 3.1.2 * cri-o 1.20 - through dnf module enable cri-o:1.20 dnf install cri-o systemctl daemon-reload systemctl enable crio —now * and minikube for now, that I trigger using this minikube start --driver=podman --container-runtime=cri-o which kind-of works, but this is very early stage, and I’m facing a few glitches so I’d really like to find a place where I can share my findings so, a rather open question as you can see :) any insight, either general or specific, or pointer to a doc that we would have overlooked, or clue on the right place to discuss all this, would be very much appreciated — thanks !

4 4

Help Wanted: Podman Documentation contributors, suggestions, and more....
by Tom Sweeney 22 May '21

22 May '21

Recently the community discovered that the Podman Whatis?(https://podman.io/whatis.html) page had badly lagged behind the reality of Podman. For example, the page talked about the soon-to-be-released REST API (released a few months ago), and other upcoming features that were already in play. Additionally, over the past few months, inquiries have been made over the availability of several documents: specific "how-to's", a user guide, rootless container tutorials, networking tutorials, and a few issues have been lodged against various parts of the existing documentation. The maintainers of Podman have recognized that the documentation for the project is not at the level it should be, even though we have made our best effort to do so. At this point, we are hoping to get help from the community. The level of help that we would like to get is varied. At the top of the list would be creating issues (https://github.com/containers/podman/issues) for any missing or incorrect documentation. If someone in the community likes going through man pages and making sure they're formatted consistently, we'd love their help. If you ever wanted a big documentation project that you could stamp your name on, then the Podman Users Guide might be a great way to increase your documentation chops. Any help that you would be willing to offer to better Podman's documentation would be gratefully accepted. Also, if you or someone you know is not terribly technical yet wants to contribute to an Open Source project, this might be a great opportunity to get your foot in the door. We'd be more than happy to walk someone through the git submission processes in exchange for documentation improvements for the project. Or if they're more comfortable sending in something via email, we'd be happy to deal with the git side of things. So if you have documentation improvement ideas or suggestions, please add a comment to the discussion here (https://github.com/containers/podman/discussions/10336) or send an email to the Podman mailing list (https://lists.podman.io/admin/lists/podman.lists.podman.io/) Paraphrasing Richard Branson: No idea is too small, and all sorts of ideas have the potential to change the project as we know it for the better. We have an absolutely terrific and growing Podman community. Hopefully, this effort will garner more contributors and create better documentation for Podman. Thanks for your attention, and feel free to contact me if you have any questions. Best Wishes, Tom Sweeney tsweeney(a)redhat.com

4 5

CIFS share as a volume
by rem＠llgc.org.uk 21 May '21

21 May '21

Hi, I have a problem mapping a cifs network share to a container. It's an auto-mount and from the /etc/auto.mnt I can see it's mounted with: -fstype=cifs,rw,noperm,vers=3.0 The mount is attached to the /mnt/share-name I run image of the container with: sudo podman run --pod pod-name --detach --name container-name -v /mnt/share-name:/usr/src/app/share:rw,z ......... I get: Error: failed to set file label on /mnt/share-name: operation not supported Wonder if anybody could help me and point me to the right direction. Thanks

5 18

OCI permission denied from '--uidmap'
by lejeczek 20 May '21

20 May '21

Hi guys. If I use 'uidmap' then container in a pod fails to start/run with: Error: error stat'ing file `/var/lib/containers/storage/overlay-containers/18df20ff42cbe9c48807ccd1a529696b93638d81a431161a94d7caeb1f2b6c2b/userdata/shm`: Permission denied: OCI permission denied Quite a few "OCI permission" around the net but none relating to that above I could find. What might be a solution for the issue? many thanks, L.

2 4

flaky slirp4netns - tweak it?
by lejeczek 18 May '21

18 May '21

Hi guys. I have a container which "suffers" from quite inacceptable link quality to host's iface - container apps timeout often - but that "same" container (in both cases in a pod) when rootful and on cni works apparently perfectly, certainly does not see issues rootless sees. Is it possible, in or outside of podman to tweak bits, maybe kernel's, in order to troubleshoot it? many thanks, L. podman-3.0.1-6.module_el8.5.0+736+58cc1a5a.x86_64 4.18.0-301.1.el8.x86_64

1 0

extra tap iface in rootless container - ?
by lejeczek 15 May '21

15 May '21

Hi guys. Either it was there always and I was blind, though I go rootless very rarely, or my podman recently started this: # ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether d2:d4:62:b4:d7:61 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.88.2.3/24 brd 10.88.2.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::d0d4:62ff:feb4:d761/64 scope link valid_lft forever preferred_lft forever 4: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000 link/ether 6e:f7:55:d0:42:91 brd ff:ff:ff:ff:ff:ff inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0 valid_lft forever preferred_lft forever inet6 fe80::6cf7:55ff:fed0:4291/64 scope link valid_lft forever preferred_lft forever You can see 'eth0@if5' came from cni network but what that 'tun0' is doing there? Every rootless container on my box gets it. many thanks, L.

2 2

post-mortem: podman v3.2.0-rc1 in fedora stable updates
by Lokesh Mandvekar 12 May '21

12 May '21

Hi list, First off, my apologies to all users for shipping a bad podman update in the yum repos. What Happened ------------- Few days ago, podman v3.2.0-rc1 mistakenly got pushed to the stable updates repositories on Fedora 33 and 34. Why It Happened --------------- The packaging automation for container tools regularly tries to push any bodhi updates in testing state to stable. While I had already disabled autokarma for any bodhi update containing an RC build, I forgot to disallow `request push to stable` for any bodhi containing an RC build via the automation. Also, there were no gating test failures for said bodhi updates so the stable pushes completed without complaints. Current Resolution ------------------ Since a stable podman v3.2.0 is still quite a few days away, I have reverted podman rpm to v3.1.2 with an Epoch bump 2 -> 3. Bodhi updates for those can be found here: Fedora 33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0ce79fff2a Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-51708c90bc Future Steps ------------ I have added a check in the packaging automation to block any RC builds from being pushed to stable, so this issue should never occur again. If anybody is interested, the automation script can be found here: https://gitlab.com/rhcontainerbot/pkg-builder/-/tree/fedora Next month, I plan to work on moving the packaging automation into Podman upstream with Packit integration (https://packit.dev/) which should provide further improvements in quality control. Thanks and apologies once again. -- Lokesh IRC, GitHub: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5

1 0

Delta 8 Products
by Roxanna Granger 10 May '21

10 May '21

One of the best Delta cordless drills is the Proactor model. The proactor model features a one-year warranty and is constructed of high quality materials. This Delta product definitely lives up to its name. It has received many favorable comments from both Delta customers and those who have purchased other brands of Delta power tools. The Delta brand is well known for reliability, durability and being able to take on tough jobs with ease. While you are searching for the best Delta cordless drill, you will find they are available in several different sizes and models. If you are in the market for purchasing one of these power tools, you should definitely consider the Proactor model. You are sure to receive many positive comments and reviews once you start using this popular Delta cordless drill. If you are interested in trying other good delta 8 products, have a look at https://area52.com/products/delta-8-tincture/

2 1

no logs from container
by lejeczek 04 May '21

04 May '21

Hi guys I'm trying a popular image, perhaps very popular(not sure if with podman consumers though) off which a rootful container produces no logs. I've tried podman vers 2.0 & 3.1, with the same results. Adding debug to: -> $ podman container restart cni-net.disc --log-level=debug ... INFO[0000] Running conmon under slice machine-libpod_pod_6ef5202d6954f3616a530f188954465e27ff4730dfad32b68d9467c26e789d18.slice and unitName libpod-conmon-7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97.scope DEBU[0000] Received: 310116 INFO[0000] Got Conmon PID as 310113 DEBU[0000] Created container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 in OCI runtime DEBU[0000] Starting container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 with command [/bin/bash] DEBU[0000] Started container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 DEBU[0000] Called restart.PersistentPostRunE(podman container restart cni-net.discourse --log-level=debug) does not reveal much as you can see. I can: -> $ podman exec -it cni-net.disc sh and shell is availble. How to troubleshoot issues like this? many thanks, L.

2 9

rootless-cni-infra - when & how?
by lejeczek 04 May '21

04 May '21

Hi guys. I assume that 'rootless-cni-infra' gets created somewhere under the hood without user intervention and I wonder how and when, as I see this: .. ERRO[0000] error starting some container dependencies ERRO[0000] "rootless CNI infra image not present - please build image from https://github.com/containers/podman/blob/v3.0.1-rhel/contrib/rootless-cni-… and tag as \"rootless-cni-infra\"" Error: error starting some containers: internal libpod error Would somebody care to shed some light on it? many thanks, L.

1 0