podman and kubernetes
by Thierry Parmentelat
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-...
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 years
Help Wanted: Podman Documentation contributors, suggestions, and more....
by Tom Sweeney
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 years
CIFS share as a volume
by rem＠llgc.org.uk
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
4 years
OCI permission denied from '--uidmap'
by lejeczek
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.
4 years
flaky slirp4netns - tweak it?
by lejeczek
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
4 years
extra tap iface in rootless container - ?
by lejeczek
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.
4 years
post-mortem: podman v3.2.0-rc1 in fedora stable updates
by Lokesh Mandvekar
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
4 years
Delta 8 Products
by Roxanna Granger
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/
4 years
no logs from container
by lejeczek
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.
4 years, 1 month
rootless-cni-infra - when & how?
by lejeczek
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-cn...
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.
4 years, 1 month
