Because the test left the image mounted the cleanup failed to remove the
tmpdir as it contained an active mount point. Thus ensure we unmount the
image again to prevent this leak.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Using /tmp means this file will be leaked and no deleted, switch to
using the per test tempdir which is removed after the test.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
TMPDIR is typically /tmp which is typically(*) a tmpfs.
This PR ignores $TMPDIR when $CI is defined, forcing all
e2e tests to set up one central working directory in /var/tmp
instead.
Also, lots of cleanup.
(*) For many years, up to and still including the time of
this PR, /tmp on Fedora CI VMs is actually NOT tmpfs,
it is just / (root). This is nonstandard and undesirable.
Efforts are underway to remove this special case.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Cache cleanups only happen if there is a cache miss, and we need to pull a new image
For quay.io/podman/machine-os, we remove all old images from the cache dir. This means we will delete any file that exists in the cache dir; this should be safe to do since the machine pull code should be the only thing touching this cache dir. OCI machine images will always have a different manifest, and won’t be updated with the same manifest, so if the version moves on, there isn’t a reason to keep the old version in the cache, it really doesn’t change.
For Fedora (WSL), we use the cache, so we go through the cache dir and remove any old cached images, on a cache miss. We also switch to using ~/.local/share/containers/podman/machine/wsl/cache as the cache dir rather than ~/.local/share/containers/podman/machine/wsl. Both these behaviors existed in v4.9, but are now added back into 5.x.
For generic files pulled from a URL or a non-default OCI image, we shouldn’t actually cache, so we delete the pulled file immediately after creating a machine image. This restores the behavior from v4.9.
For generic files from a local path, the original file will never be cleaned up
Unsure how to test, so:
[NO NEW TESTS NEEDED]
Signed-off-by: Ashley Cui <acui@redhat.com>
This PR adds libkrun support to podman machine. This is an experimental feature and should not be marketed yet. Before we unmark the experimental status on this function, we will need to have full CI support and a full podman point release has pased.
This work relies on the fact that vfkit and libkrun share a reasonably (if not perfectly) same API. The --log-level debug option will not show a GUI screen for boots as krun is not capable of this.
Signed-off-by: Brent Baude <bbaude@redhat.com>
The fedora image reviewers wanted to use for make validatepr is not
being being built as a multiarch image. Use quay.io/libpod/validatepr
instead.
Signed-off-by: Brent Baude <bbaude@redhat.com>
It is not clear why rootless was forced to the cgroupfs manager when
systemd is the default. In any case it causes local test failures as
described in the issue[1]. Using systemd manager makes them pass as
expected, I don't know enough aout cgroups to know the difference and
why certain tests have bad asumptions but this fixes it.
[1] https://github.com/containers/podman/issues/22474
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Both tests need the podman-registry script in $PATH, this never worked
locally as only the cirrus specific CI setup scripts configured this.
To make it work correctly locally add the hack dir to $PATH for these
Makefile targets.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This doesn't do anything and I was unable to find anything in the git
history when or why it was added. The HACK var is just adding another
directory to the ginkgo argument list. As the only arg used was the
"./hack" dir which does not contain any go files it does nothing
besides confusing me about its purpose.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When the source dir is already mounted noexec, nodev or nosuid then a
rootless user cannot mount the dir into the container without these
options for obvious reasons.
So in order to run the test we must ensure the dir is mounted with these
options first, if they are simply skip as the test will fail otherwise.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When you run locally with a higher oom_score_adj then the one used in
the test podman will print a warning and not set the oom lower then the
current value. Thus use 999 as value which should only cause problems
for users with oom_score_adj value of 1000 (max value) which seems
unlikely.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Effectively, this is an ability to take an image already pulled
to the system, and automatically mount it into one or more
containers defined in Kubernetes YAML accepted by `podman play`.
Requirements:
- The image must already exist in storage.
- The image must have at least 1 volume directive.
- The path given by the volume directive will be mounted from the
image into the container. For example, an image with a volume
at `/test/test_dir` will have `/test/test_dir` in the image
mounted to `/test/test_dir` in the container.
- Multiple images can be specified. If multiple images have a
volume at a specific path, the last image specified trumps.
- The images are always mounted read-only.
- Images to mount are defined in the annotation
"io.podman.annotations.kube.image.automount/$ctrname" as a
semicolon-separated list. They are mounted into a single
container in the pod, not the whole pod.
As we're using a nonstandard annotation, this is Podman only, any
Kubernetes install will just ignore this.
Underneath, this compiles down to an image volume
(`podman run --mount type=image,...`) with subpaths to specify
what bits we want to mount into the container.
Signed-off-by: Matt Heon <mheon@redhat.com>
Image volumes (the `--mount type=image,...` kind, not the
`podman volume create --driver image ...` kind - it's strange
that we have two) are needed for our automount scheme, but the
request is that we mount only specific subpaths from the image
into the container. To do that, we need image volume subpath
support. Not that difficult code-wise, mostly just plumbing.
Also, add support to the CLI; not strictly necessary, but it
doesn't hurt anything and will make testing easier.
Signed-off-by: Matt Heon <mheon@redhat.com>
Followup to [1]#22270: wherever possible/practical, extend command
error checks to include explicit exit status codes and error strings.
Just trying to shrink down #22346 to a manageable, reviewable size.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Followup to #22270: wherever possible/practical, extend command
error checks to include explicit exit status codes and error strings.
More low-hanging fruit: small reviewable chunks
Signed-off-by: Ed Santiago <santiago@redhat.com>
Followup to #22270: wherever possible/practical, extend command
error checks to include explicit exit status codes and error strings.
Because #22346 is stalled, these are some trivial easy-to-review
changes that get us closer to the goal.
Signed-off-by: Ed Santiago <santiago@redhat.com>
The contents of the "Prerequisite before buil"d section are given already
in a link in its "Prepare your environment" parent section and therefore
redundant. Let's remove it.
Signed-off-by: phoenix <felix.niederwanger@suse.com>
Adds the installation instructions for openSUSE, similar to the present
ones for Fedora and Debian/Ubuntu.
Tested on openSUSE Tumbleweed and Leap 15.6.
Signed-off-by: phoenix <felix.niederwanger@suse.com>
