This way has a huge disadvantage: The user will not see an error when he
uses a non-existent option. Another disadvantage is, that if we add more
options within podman, they might collide with the names chosen by
plugins. Such issues might be hard to debug.
The advantage is that the usage is very nice:
--network bridge:opt1=val1,opt2=val2.
Alternatively, we could put this behind `opt=`, which is harder to use,
but would solve all issues above:
--network bridge:opt=opt1=val1,opt=opt2=val2
Signed-off-by: Michael Zimmermann <sigmaepsilon92@gmail.com>
Final cleanup. Has been working fine in #23257 for weeks.
Not much gain here, but every little bit helps.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Fix the issue where podman machine init does not create
all the necessary machine files when ignition-path is used. Fixes: #23544
Signed-off-by: Graceson Aufderheide <gracesonphoto@gmail.com>
commit 5ebba75dbd implemented this
behaviour for rootless users, but the same limitation exists for any
user in a user namespace. Change the check to use the clamp to the
current values anytime podman runs in a user namespace.
Closes: https://github.com/containers/podman/issues/24508
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
All the backend work was done a while back for image volumes, so
this is effectively just plumbing the option in for volumes in
the parser logic. We do need to change the return type of the
volume parser as it only worked on spec.Mount before (which does
not have subpath support, so we'd have to pass it as an option
and parse it again) but that is cleaner than the alternative.
Fixes#20661
Signed-off-by: Matt Heon <mheon@redhat.com>
First, creating a global file /etc/system-fips was never a good idea for
testing as it affects other running tests at the same time.
And as of a recent change to FIPS mounts[1] we no longer use the file so
the test breaks with c/common v0.61. Instead it uses the kernel file
/proc/sys/crypto/fips_enabled which requires the real fips mode to be
activated and that in turn requires a reboot. As such this is not
somthing that can be tested in upstream CI like that.
[1] https://github.com/containers/common/pull/2174
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Previous version was badly broken: it relied on 'make'
rebuilding a file under cwd, which is a no-no; and, in
the case where we don't have a source directory, just
blindly hoped that there'd be a system-installed .service
file with the correct path to podman.
Solution:
. if running in source directory, run sed directly into
destination service file in $UNIT_DIR. This is ugly
duplication of a line in Makefile.
. if NOT running in a source directory, check $PODMAN:
. if it's /usr/bin/podman, continue. Include a warning
that will be shown only on test failure.
. otherwise skip, because we don't know what we're testing
Signed-off-by: Ed Santiago <santiago@redhat.com>
* treadmill script: handle an obscure corner case
wherein the script would bail because it thought
there were no buildah-vendor changes.
* two new test skips
* update the diffs; line-number changes due to buildah
PRs touching helpers.bash
Signed-off-by: Ed Santiago <santiago@redhat.com>
- fix issues found by recvcheck
- skip k8s files from recvcheck
- remove two removed linters gomnd and execinquery
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This function is not used, we pull actual container images for testing
now. This allows us to remove github.com/coreos/stream-metadata-go.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Up to now this test has been run using:
PODMAN_TIMEOUT=2 run_podman kube play ...
...and this gives podman time to start the pod before getting
the signal.
When run in parallel, under heavy load, the above command seems
to time out before podman has gotten its act together. Weird
things happen, like weird exit status and (most crucially)
zombie containers.
Solution: wait for container to actually start before we kill it.
Signed-off-by: Ed Santiago <santiago@redhat.com>
