The timeout is simply to low, I don't know the previous numbers were
collected because they are simply wrong. A machine init takes around 50s
total. And while the ready timeout itself could be shorter there is
really no good reason to set such a low limit as it will cause wrong
failures.
This is currently flaking a lot in CI, I see it in most hyperV logs I
looked at[1]. While there is likely another problem with the boot
failures I think this added a ton of false positives as it errors out
early.
[1] https://github.com/podman-container-tools/podman/actions/runs/34146238887/job/101820830173
Fixes: dd28c14f8c ("hyperv: add timeout to vsock ready wait")
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
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>
Since I use go 1.26 the go fix does not have all the rules built in,
there are newer ones in modernize so run the explicitly to fix more code
for go 1.26.
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>
ostree.go is limited to only amd64 and arm64, but its tests run on all
architectures and fail because all their symbols are missing.
Don't run tests on an architecture where the non-test code doesn't
exist.
References: https://github.com/podman-container-tools/podman/issues/29711
Signed-off-by: Hugo Osvaldo Barrera <hugo@whynothugo.nl>
When starting a machine on Windows, background helper processes
(podman.exe machine server9p, gvproxy, and win-sshproxy) could be
terminated when the parent CMD/PowerShell session closed.
1. For podman.exe machine server9p (a console subsystem binary), set
CreationFlags to CREATE_NO_WINDOW so it runs without attaching to
the parent console.
2. For GUI binaries (gvproxy and win-sshproxy), configure
DETACHED_PROCESS so they outlive the invoking console session.
Fixes: #29573
Signed-off-by: prabhat-kumar96 <prabhatmathur9927@gmail.com>
Replaces regexp.MustCompile with regexp.Delayed from go.podman.io/storage/pkg/regexp
for global regular expressions. This avoids compiling regular expressions
during the global init scope, improving startup performance for all commands.
Tests are kept using regexp.MustCompile where applicable.
Fixes: #29510
Signed-off-by: Vishnu Kothakapu <vishnukothakapu27@gmail.com>
When passing an error to fmt.Errorf or logrus with formatting verbs like
%v or %w, it is not necessary to explicitly call err.Error(). The format
functions will automatically call the Error() method because the value
implements the error interface. Removing these explicit calls makes the
code cleaner and more idiomatic.
Fixes: #29501
Signed-off-by: Vishnu Kothakapu <vishnukothakapu27@gmail.com>
ListenSetupWait() waited on errChan with no timeout, so podman machine
init/start could hang forever if the guest never signaled ready. Added
waitForReady(errChan, timeout) with a 30 second bound. Full details in
the issue.
Fixes: #29455
Signed-off-by: Rudra Dudhat <contact.rdudhat@gmail.com>
The InstalledProviders and SupportedProviders functions were only
used in their own tests and were otherwise dead code. Removing them
entirely cleans up the API surface.
Signed-off-by: Aryanbhargava18 <aryanbhargava644@gmail.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>
Remove the just provisioned WSL distribution if one of the post install
scripts fail.
Fixes#27036
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
