After the VM has successfully started, check that gvproxy is
still running. If it is not, throw an error and refuse to
complete machine start.
[NO NEW TESTS NEEDED] I don't think we can deliberately trigger a
bad gvproxy start without a bad Podman binary. We could try and
kill gvproxy after it starts but before the machine is booted but
that's very prone to races.
Slightly restructure code so that starting shares happens later
and has its own configuration write - so the VM is still recorded
as running if starting shares fails.
Signed-off-by: Matt Heon <mheon@redhat.com>
Create a buildah SystemContext from the existing cli arguments
Pass the SystemContext to the build
Add system test
Signed-off-by: Ygal Blum <ygal.blum@gmail.com>
Began as a review of #20983, a community PR from @krumelmonster
for moving divisive-language footnotes closer to the point
where they're used. In the process, I noticed a lot of poor
markdown, mostly bad use of whitespace. Cleaned it up, added
some italic/bold/tty markdown to options, and cleaned up
some language I found confusing.
Thanks to @krumelmonster for initial PR.
Signed-off-by: Ed Santiago <santiago@redhat.com>
A number of tests start a container then immediately run podman stop.
This frequently flakes with:
StopSignal SIGTERM failed to stop [...] in 10 seconds, resorting to SIGKILL
Likely reason: container is still initializing, and its process
has not yet set up its signal handlers.
Solution: if possible (containers running "top"), wait for "Mem:"
to indicate that top is running. If not possible (pods / catatonit),
sleep half a second.
Intended to fix some of the flakes cataloged in #20196 but I'm
leaving that open in case we see more. These are hard to identify
just by looking in the code.
Signed-off-by: Ed Santiago <santiago@redhat.com>
When performing CheckExclusiveArch, we should get a list of VMs that
exist on disk (JSON). We should then iterate those and checking if they
are running in HyperV.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
this default value for podman machine disk sizes is 100GB. On CI
platforms where the IO is slow and some operations are not done
sparsely, this can really slow things down.
if no disk size is provided by the init command in the test suite, we
set it to 11G.
Signed-off-by: Brent Baude <bbaude@redhat.com>
The push binding endpoint wasn't actually writing the
output data to the stream when quiet=false and there
was no push error.
Do not hard code quiet=true anymore, take into account the
user input.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
Our test registry (used for login & local registry tests)
was being run using the standard podman tmpdir, hence the
standard podman database, This was then getting clobbered
in the 330-corrupt-images test, which runs "system reset".
We just didn't know this was happening. Until we added
a registry test after the system reset. Oops.
Solution: new helper function podman_isolation_opts()
sets --root, --runroot, *and --tmpdir*. Refactor all
existing --root/--runroot usages. Document.
Next problem: the "network reload" test in 500-networking.bats
did not (could not) know about our registry port, so the
"iptables -F" command reverted that to DROP, so the subsequent
podman-auth in 700-play timed out.
Solution: add a podman-isolated "network reload" to start_registry().
Final problem, because, really, those weren't enough: a BATS
bug where running with --filter-tags would set IFS=',' in setup_suite
which in turn has catastrophic consequences:
https://github.com/bats-core/bats-core/issues/812
See #20966 for details of the failure and further conversation.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Also Support for podman pod ps --format '{{ .Label label }}'
Finally fix support for --format '{{ .Podname }}'
When user specifies .Podname this implies --pod was passed.
Fixes: https://github.com/containers/podman/issues/20957
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
This field drags in a dependency on CNI and thereby blocks us from disabling CNI
support via a build tag
[NO NEW TESTS NEEDED]
Signed-off-by: Dan Čermák <dcermak@suse.com>
It seems CI generally needs a little more of a default timeout to
complete the init and boot process of a machine. This extends the
timeout from 90 seconds to 240 seconds.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
The following PR is the very first step in what will a series of steps
to apply a "common" machine configuration file to all providers.
Function names, method names, struct names, and field names are all up
for debate. The purpose of this PR is to offer a glimpse at the
direction we intend to take.
This PR also contains temporary structs (i.e. aThing) that are not
exported. These are merely placeholders.
The configuration work in this PR is also unused of yet. But the code
is compiled. Once merged, we can begin the next step of development.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
Because the podman machine tests normally run at the end of the chain,
it's time consuming for developers to validate machine-only changes.
Support a special CI runtime mode, only when a PR is marked as a draft.
Update related documentation
Also: Only run machine tests on PRs, never for branches or new tags.
Signed-off-by: Chris Evich <cevich@redhat.com>
If a user did not set an equal sign in the annotation that old code
would panic when accessing the second element in the slice.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This option accepts a file path so we should allow commas in it.
There ar eno tests for this option, I have no idea what this option does
nor how to use it so I cannot write one.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This option accepts a file path so we should allow commas in it.
Also add tests for --decryption-key
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
WSL is unable to set or change CPU/memory settings. We should not test
for them.
Skip one test and filed issue #20978
Signed-off-by: Brent Baude <bbaude@redhat.com>
Like stated in [PR for crun](https://github.com/containers/crun/pull/1372)
that HostID is what being mapped here, so we should be checking `HostID` instead of `ContainerID`. `v.ContainerID` here is the id of owner of files on filesystem, that can be totally unrelated to the uid maps.
Signed-off-by: Karuboniru <yanqiyu01@gmail.com>
