honor eventual options set in the containers.userns setting in the
containers.conf file, e.g.:
[containers]
userns = "auto:size=8192"
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Quadlet was doing some custom handling of uid/gid remapping, originating
from pre --userns=auto support, including its own user for getting subuids
which kinda conflicts with the "container" user used for that.
This drops all the old support for id remapping in favour of a new set
of keys that more directly map to the podman run options.
We have essentially 3 modes now:
```
RemapUsers=manual
RemapUid=0:10000:10
RemapUid=10:20000:10
RemapGid=0:10000:10
RemapGid=10:20000:10
```
This maps to --uidmap and --gidmap options.
```
RemapUsers=auto
```
This maps to --userns=auto. But you can additionally specify RemapUid,
RemapGid and RemapUidSize which gets applied as options to the
--userns podman option.
```
RemapUsers=keep-id
```
This maps to --userns=keep-id and only works for user units.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
The checkout action by default, clones the current repository. However,
since this workflow is re-used by other repos, and it calls scripts in
the podman repo, those calls will all fail. Fix this by hard-coding the
podman repo.
Ref: https://github.com/actions/checkout
Signed-off-by: Chris Evich <cevich@redhat.com>
The 900-ssh test is not an actual test, and I'm unable to
figure out how to make it one. Skip it for now, but add a
bunch of FIXMEs some someone can come in later and actually
implement it.
Also removed lots of dead code and misleading comments.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Depending on the backend (CNI, netavark) we support different drivers,
the auto completion should only suggest the ones that are available.
This list is podman info so we can get the correct list for local and
remote.
[NO NEW TESTS NEEDED]
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Some error reporting logic got lost from (*Container).prepare during the
port. This adds the missing logic, similar to the Linux version.
[NO NEW TESTS NEEDED]
Signed-off-by: Doug Rabson <dfr@rabson.org>
The current test uses registry.redhat.io which does not support unauthenticated access
Replace the registry with registry.access.redhat.com which does
Signed-off-by: Ygal Blum <ygal.blum@gmail.com>
1. proxy value from env `CONTAINER_PROXY`
2. proxy socks5 && socks5h is supported
3. the proxy dial timeout is 3s
Signed-off-by: shuai.yang <shuai.yang@mihoyo.com>
Including the RawInput in the API output is meaningless.
Fixes: #16497
[NO NEW TESTS NEEDED]
Signed-off-by: Toshiki Sonoda <sonoda.toshiki@fujitsu.com>
...not as a separate post-main step. Reasons:
1) If main test times out, Cirrus won't run subsequent steps
2) It really belongs in the main log anyway, because when
looking at test results, you want to have instant access
to versions, you don't want to have to clickety-click
ten steps.
Signed-off-by: Ed Santiago <santiago@redhat.com>
It's so easy to forget that "podman start" is nonblocking.
So podman create, start, restart has a race where "restart"
can run before the container actually starts.
Solution: start --attach. Thanks to @vrothberg for noticing that.
There are still a handful of other suspicious-looking restarts
in this test, but all involve "top" which of course has to be
detached. Since those don't have any flakes that I know of, I
choose to ignore them.
Fixes: #16505
Signed-off-by: Ed Santiago <santiago@redhat.com>
Podman --noout was not suppressing output from commands that do not
create the podman engine. Now, podman --noout properly suppresses output
from every command.
Fixes: https://github.com/containers/podman/issues/16201
Signed-off-by: Ashley Cui <acui@redhat.com>
No issue filed, because I thought these were related to 16132.
They're not: they're actual test bugs, running "play kube"
without actually waiting for the container to run. Fix that.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Weird one-off flake seen:
# ... healthcheck run <containername>
Error: container SHA is not running
The only way I can see this happening is if the healthcheck
auto-timer triggered, which seems impossible because that
should be 30s and the log timestamps show this test taking
18s. But, shrug, let's see if disabling the timer works. I
don't have high hopes that this will fix anything, but it's
probably a good idea regardless.
Also, since this test loops over different policies, include
policy name in error messages as a courtesy. (It's obtainable
anyway by scrolling up)
Signed-off-by: Ed Santiago <santiago@redhat.com>
