Even on the slowest of CI systems a normal VM start does not seem to
take more than 1 minute.
Instead we seem to have flakes which cause our command to hang on
startup. In that case we thought waiting longer might help but instead
it just wastes 10 minutes.
Se the default command timeout to 3 minutes which should be plenty even
on the slowest of CI systems. Anything above will likely never finish
and we can just abort the test as failed.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Combine the no volume and --import-native-ca test into one.
This removes one full machine init/start/stop cycle.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Instead of creating a fresh machine which is slow reuse an existing
test for this test.
Also fix the test to actually check the file content properly, it was
using the wrong build output. And then just use one cat for both files
to make it a tiny bit faster.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Only start a machine once, not three times to safe time.
Also include stdout/err as part of the curl command so errors are
visible. And lastly the latest moby client code should support unix
sockets on windows so we can test it there as well.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Instead of having to start a new machine again here just drop the test
and do the stop check as part of another test which already has a
machine running.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The test should fail before booting a real VM so we can use the fake
image which should make the test a few seconds faster.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The test starts a machine 3 times taking almost 180 seconds in linux CI.
We have a lot of machine starts elsewhere already so we really do not
need a basic start and for the quiet/noinfo checks we can just add them
to another existing start command.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Each machine start/stop adds up in CI, combine several related tests to
reduce the machine init/start/stops cycles.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
On podman machine set we have three modes, not set (keep user),
--rootful (set user to root), --rootful=false (set to rootless user).
The later could not be passed at all before this.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The restart tests are rather slow. On the linux CI 60 seconds for the
stopped case and almost 120 seconds for the restart running case.
Combine both cases into one so we only have to start a machine twice,
not three times and only need to init it once.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Plus manually deleting the left over inline functions because go fix
doesn't do that even though they are private functions.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Add one more test to the basic podman commands e2e tests:
- starts an HTTP server on the host
- verify HTTP requests from a container, using
`host.containers.internal` or `host.docker.internal`, are routed
successfully to the server running on the host
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
test
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
The lookup for the gvproxy process was broken on Windows:
- We looked for gvproxy, not gvproxy.exe, and `tasklist` was always
failing
- But `pgrep` wasn't failing because we looked for the wrong `tasklist`
error message (the correct error message on my laptop is "INFO: No tasks
are running which match the specified criteria.")
- WSL uses win-sshproxy.exe, not gvproxy.exe
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
The current systemd service to mount /etc/containers is not working
right. The Before=podman.socket causes a ordering conflict which causes
the socket to be disabled and thus all podman remote connections fail.
The problem is the unit is wanted by the default.target while the socket
is wanted by sockets.target which can be before the default.target is
triggered. That means that the Before= line cannot be fulfilled and
sometimes systemd thus seems to not start the socket. It is unclear to
me why this is racy as it is sometimes also works.
This was reported by Vladimir Lazar from the PD team, our CI did not
caught this as we use rootless machines by default and the problem only
happens for the rootful socket so we do not see connection failures.
To fix this add at least one rootful socket check.
We do however have a different CI flake that was also caused by the
incorrect mount dependencies. The mount could happen after sshd or other
programs run. So to fix this we must hook the podman-mnt-config.service
into the local-fs.target which runs much earlier and is used for all the
mounts.
Fixes: #29003
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
With podman 6 we have a --import-native-ca option that handles the
copying of certs much better.
As such remove our old legacy way of copying files these envs and also
the static certs.d dir. Since we now mount the full containers config
dir the certs from the cert.d are mounted already.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Each machine init boot takes a while, we can easily do this as part of
one test run to speed the overall machine test time up.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The podman module paths are moving from github.com/containers/podman to
go.podman.io/podman. This will help with future mobility.
Signed-off-by: Brent Baude <bbaude@redhat.com>
This was implemented by containers/netavark #1369; this commit
completes the process by wiring it into Podman. We now respect
the CLI order for configured networks - if a user passes
`--net net1,net2` we guarantee that net1 will be configured
before net2.
For containers created before this patch, we don't retain enough
information to configure networks in CLI order, so we use
alphabetical order instead to still guarantee consistency.
No breaking API changes have been made, but we do add a new
field to supplement the existing map to (optionally) provide
ordering information. The Podman CLI will always pass this.
Existing applications that do not will, again, receive]
deterministic ordering based on an alphabetical sort of network
names.
This requires the latest version of Netavark to work properly.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Replace github.com/docker/docker API imports with github.com/moby/moby
across compat handlers, swagger models, and tests to align with upstream
type definitions.
Fixes: #27536.
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
closes: #27411
Adjust SUB_UID and SUB_GID ranges to support running rootless Podman inside a rootless run Podman container.
Also add a test to verify the change and prevent regression.
By default, a new user is assigned the following sub-ID ranges:
SUB_UID_MIN=100000, SUB_GID_MIN=100000, SUB_UID_COUNT=65536, SUB_GID_COUNT=65536
This means the user’s sub-UID and sub-GID ranges are 100000–165535.
When the container is run rootless with the user defined below, ID mappings occur as follows:
- Container ID 0 (root) maps to user ID 1000 on the host (which is the user created below).
- Container IDs 1–65536 map to IDs 100000–165535 on host (the subid range previously mentioned).
If a new user is created inside this container (to build containers for example), it will
attempt to use the default sub-ID range (100000–165535). However, this exceeds the container’s
available ID mapping, since only IDs up to 65536 are mapped. This causes nested rootless Podman
to fail.
To enable container-in-container builds, the sub-ID ranges for the user must be large enough
to provide at least 65536 usable IDs. A minimum SUB_UID_COUNT and SUB_GID_COUNT of 165536 is
required, but 1,000,000 is used here to provide additional margin.
1,000,000 matches the subid range other machines are using, defined in [ignition.go](69b397af49/pkg/machine/ignition/ignition.go (L284-L289)).
The script of other machines modify the subid files directly for 1 user, the `sed` command used in
this fix mimics that.
The test is added as en extension to the 'simple init with username' test case, to prevent having
to create a new VM.
Signed-off-by: dvorst <87502756+dvorst@users.noreply.github.com>
runWslCommand never returns err != nil because if there's an error, it
calls Fail (which panics, so the code after it is unreachable).
Remove error returning and checking.
Inspired by the following linter warning:
> pkg/machine/e2e/config_windows_test.go:59:56: runWslCommand - result 1 (error) is always nil (unparam)
> func runWslCommand(cmdArgs []string) (*machineSession, error) {
> ^
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
When starting a machine and the user has not explicitly passed
-u=true|false AND stdin is a not a tty, we should not prompt to update
connections.
Fixes: #27556
Signed-off-by: Brent Baude <bbaude@redhat.com>
Now that Podman 6.0 no longer supports Intel Macs, use libkrun as the
default machine provider.
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
this pr is a follow on to #27493. it adds support for hyperv "fake"
images and suggests a benefit in terms of test speed. for hyperv, we
create a generic 4MB vhdx and stick it into the temp dir. this saves us
from any image copy or compression.
i also followed up on a few comments Paul made about using windows|unix
instead of each platform.
Signed-off-by: Brent Baude <bbaude@redhat.com>
While doing the provider obfuscation, I injected a regression where
podman ssh machine failed. The regression was added in
0f22c1c772. I have fixed the regression
and added a test to prevent future occurance.
Fixes: #27491
Signed-off-by: Brent Baude <bbaude@redhat.com>
