Flag is actually named `rootful` however documented as `root`, fix the
documented example as actual flag.
Both `podman machine init` and `podman machine set` uses flag `rootfull`
[NO TESTS NEEDED]
[NO NEW TESTS NEEDED]
Signed-off-by: Aditya R <arajan@redhat.com>
The PlayKube and PlayKubeDown commands accepted a "path" argument to a YAML file
to play. This requires the caller to write the YAML to a file path. The downside
of this is apparent in the HTTP handlers which have to use a temporary file on
disk to store the YAML file.
The file is opened & used as the body of the HTTP request. It's possible to
instead pass a io.Reader and use a fully in-memory request body.
Add backwards-compatible changes to bindings to allow passing either a filepath
or a io.Reader body.
Refactor the podman bindings to use a io.Reader instead of a filepath.
Simplify the HTTP handlers for PlayKube by removing the now unneeded tempfile.
[NO NEW TESTS NEEDED]
Signed-off-by: Christian Stewart <christian@paral.in>
Command flags (OPTIONS) in man pages have to date been in
haphazard order. Sometimes that order is sensible, e.g.,
most-important options first, but more often they're
just in arbitrary places. This makes life hard for users.
Here, I update the man-page-check Makefile script so it
checks and enforces alphabetical order in OPTIONS sections.
Then -- the hard part -- update all existing man pages to
conform to this requirement.
Signed-off-by: Ed Santiago <santiago@redhat.com>
When starting a VM that has been configured with volume mounts, the
podman client attempts to connect via TCP to localhost, which runs
gvproxy to proxy an ephemeral port to the VM's ssh port. Previously,
gvproxy was listening on all interfaces and IP addresses, but this
behavior has changed to listening only on the IPv4 loopback address.
Without this change, if a newer build of gvproxy is used, a podman
machine configured with volume mounts will hang forever after "podman
machine start" with "Waiting for VM ...".
[NO NEW TESTS NEEDED]
Signed-off-by: Burt Holzman <burt@fnal.gov>
Every exec session run attached will, on exit, do two things: it
will signal the associated `podman exec` that it is finished (to
allow Podman to collect the exit code and exit), and spawn a
cleanup process to clean up the exec session (in case the `podman
exec` process died, we still need to clean up). If an exec
session is created that exits almost instantly, but generates a
large amount of output (e.g. prints thousands of lines), the
cleanup process can potentially execute before `podman exec` has
a chance to read the exit code, resulting in errors. Handle this
by detecting if the cleanup process has already removed the exec
session before handling the error from reading the exec exit
code.
[NO NEW TESTS NEEDED] I have no idea how to test this in CI.
Fixes#13227
Signed-off-by: Matthew Heon <mheon@redhat.com>
Allows users to set `--os` , `--arch` and `--variant` of the image
created from the custom import.
Following is useful when user is already aware of the values which are
correct for their generated rootfs
Signed-off-by: Aditya R <arajan@redhat.com>
The documentation files for `Containerfile` and `containerignore` have
been moved from the `buildah` repository to the `common` repository.
ref: https://github.com/containers/buildah/commit/488e8654ea
Signed-off-by: John Kristensen <john@jerrykan.com>
We can just calculate the cpu percent for the time the container is
running. There is no need to use datapoints.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When you run podman stats, the first interval always shows the wrong cpu
usage. To calculate cpu percentage we get the cpu time from the cgroup
and compare this against the system time between two stats. Since the
first time we do not have a previous stats an empty struct is used
instead. Thus we do not use the actual running time of the container but
the current unix timestamp (time since Jan 1 1970).
To fix this we make sure that the previous stats time is set to the
container start time, when it is empty.
[NO NEW TESTS NEEDED] No idea how I could create a test which would have
a predictable cpu usage.
See the linked bugzilla for a reproducer.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2066145
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In general continuous-delivery (CD) tends to pair well with CI. More
specifically, there is a need for some reverse-dependency CI testing in
netavark/aardvark-dns. In all cases, the download URL needs to remain
consistent, without elements like `Build%20for%20fedora-35`.
The 'Total Success' task only ever executes when all dependencies are
successful. When a non `[CI:DOCS]` build is successful, gather all
binary/release artifacts in a new task which depends on 'Total Success'.
This will provide a uniform name (`artifacts`) and URL for downstream
users to use. For example:
https://api.cirrus-ci.com/v1/artifact/github/containers/podman/artifacts/binary.zip
or
https://api.cirrus-ci.com/v1/artifact/github/containers/podman/artifacts/binary/FILENAME
Where ***FILENAME*** is one of:
* `podman`
* `podman-remote`
* `rootlessport`
* `podman-release-386.tar.gz`
* `podman-release-amd64.tar.gz`
* `podman-release-arm64.tar.gz`
* `podman-release-arm.tar.gz`
* `podman-release-mips64le.tar.gz`
* `podman-release-mips64.tar.gz`
* `podman-release-mipsle.tar.gz`
* `podman-release-mips.tar.gz`
* `podman-release-ppc64le.tar.gz`
* `podman-release-s390x.tar.gz`
* `podman-remote-release-darwin_amd64.zip`
* `podman-remote-release-darwin_arm64.zip`
* `podman-remote-release-windows_amd64.zip`
* `podman-v4.0.0-dev.msi`
Signed-off-by: Chris Evich <cevich@redhat.com>
ginkgo netavark logs (and, to a lesser extent, cni logs)
are unreadable because the hide-boring-opts code did not
know about --network-backend. Now it does.
Manually filtered an existing netavark log to confirm there
are no other new options we should know about.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Add a CI check to prevent unwanted bloat in binary images,
by building a baseline (pre-PR) binary then comparing file
sizes post-PR.
We piggyback onto the existing 'Build Each Commit' CI check
because it gives us an easy way to run 'make' against the
parent commit.
This is part 1 of 2: adding the script, not the Makefile rule.
We can't add the Makefile rule now because the script it would
invoke does not exist in the parent commit.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Still an unknown number remains but I am running out of patience.
Adding dots is not the best use of my time.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
We need to keep disabling the `nolintlint` linter to continue using
`nolint` directives in the code.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Disabling tagliatelle would mean disabling it for hundreds of fields
that cannot be changed due to K8s or Docker or backwards compat.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Make sure we're waiting for the ls container to finish to prevent
potential flakes or future regressions.
Spotted while enabling a linter.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
