In preparation for RHEL 4.9.1, Bump Buildah to v1.33.4
This will also bump c/image to v5.29.2 and c/common to v0.57.3
This fixes a Docker Daemon version compatibility problem.
[NO NEW TESTS NEEDED]
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
Previously, every machine created using appleHV interacted with VFKit using port 8081. This meant that if multiple machines existed on the machine, starting one would start all the machines. This patch assigns a separate random port for each machine, so machine commands interact with just the specified machine.
Signed-off-by: Ashley Cui <acui@redhat.com>
LastUp now correctly reports the lastUp time for podman machine on
AppleHV, for both inspect and list.
[NO NEW TESTS NEEDED]
since this fixes an existing failing test.
Signed-off-by: Ashley Cui <acui@redhat.com>
When starting podman machine with applehv, this warning is printed:
WARN[0025] API socket failed ping test
This is due to a bug in applehv.setupAPIForwarding which is not
returning the path to the socket, which causes `WaitAndPingAPI` to be
called with `""` as the socket path, triggering the warning.
This commit changes setupAPIForwarding to be similar to the
implementation in the other machine implementations.
I don't know how to add a test for this, but this can be handled in
podman-machine end to end tests by making sure that there are no
warnings when running `podman machine start` with applehv.
[NO NEW TESTS NEEDED]
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
`applehv.Start()` has this line of code:
```
cmd.ExtraFiles = []*os.File{ioEater, ioEater, ioEater}
```
whose purpose is not clear.
The intent may have been to redirect stdin/stdout/stderr to /dev/null in
the child process.
This should be done by setting cmd.Stdin/cmd.Stdout/cmd/Stderr to nil,
which is the case by default.
The way it's done could also cause issues as
`Vfkit.VirtualMachine.Cmd()` sometimes adds files it needs to keep open
to `ExtraFiles`, so at the very least this should be an `append()`
This commit removes this code.
[NO NEW TESTS NEEDED]
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
it is the wrong check to do here since we need to setup the user
namespace even in the case we are running as root without
capabilities.
[NO NEW TESTS NEEDED] this happens in nested podman
Closes: https://github.com/containers/podman/issues/20908
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
(cherry picked from commit 1322f3193b)
Previously, the setup only checked for the CAP_SYS_ADMIN capability,
which could be not enough with containerized Podman where
CAP_SYS_ADMIN might be set for an unprivileged user.
Closes: https://github.com/containers/podman/issues/20766
[NO NEW TESTS NEEDED] needs containerized Podman
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
(cherry picked from commit 41a6b992aa)
Previously, the setup only checked for the CAP_SYS_ADMIN capability,
which could be not enough with containerized Podman where
CAP_SYS_ADMIN might be set for an unprivileged user.
Closes: https://github.com/containers/podman/issues/20766
[NO NEW TESTS NEEDED] needs containerized Podman
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Fixes a bug where a user would be unable to change
a rootless machine to rootful. Also makes sure that
the podman/docker socket service is updated if the
UID or Rootful status of the host user has been
updated.
[NO NEW TESTS NEEDED]
Fixes: #21195
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
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>
Update farm build to directly push images to a registry
after all the builds are complete on all the nodes.
A manifest list is then created locally and pushed to
the registry as well.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
The option `farm` which is used to specify the farm to be used, is moved to farm build command from farm command.
closes#20752
Signed-off-by: Chetan Giradkar <cgiradka@redhat.com>
Move the options for the podman build doc to a common md
that can be used by both podman build and podman farm build.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
This updates the Windows installer and macOS installer to ship the newer
binaries, as well as the vendored gvisor-tap-vsock code.
[NO NEW TESTS NEEDED]
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
<MH: Cherry-pick into v4.9 branch, resolve conflicts>
Signed-off-by: Matt Heon <mheon@redhat.com>
As the title says. Bumps buildah to 1.33.3, common to 0.57.2, and image
to 5.29.1. This in preparation of Podman v4.9 and RHEL 8.10/9.4.
[NO NEW TESTS NEEDED]
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
There is a network stability issue in qemu + virtio, affecting
some users after long periods of usage, which can lead to
suspended queue delivery. Until the issue is resolved, add a
temporary recovery service which restarts networking when host
communication becomes inoperable.
[NO NEW TESTS NEEDED]
Signed-off-by: Jason T. Greene <jason.greene@redhat.com>
The remote user functionality was not quite correct. This PR breaks out
the accumulation of user descriptions into a separate function. One
odditiy is ignition must be told to NOT create the core user (or it will
by default) by "adding" the core user with a set bool.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
Before this, for some special Podman commands (system reset,
system migrate, system renumber), Podman would create a first
Libpod runtime to do initialization and flag parsing, then stop
that runtime and create an entirely new runtime to perform the
actual task. This is an artifact of the pre-Podman 2.0 days, when
there was almost no indirection between Libpod and the CLI, and
we only used one runtime because we didn't need a second runtime
for flag parsing and basic init.
This system was clunky, and apparently, very buggy. When we
migrated to SQLite, some logic was introduced where we'd select a
different database location based on whether or not Libpod's
StaticDir was manually set - which differed between the first
invocation of Libpod and the second. So we'd get a different
database for some commands (like `system reset`) and they would
not be able to see existing containers, meaning they would not
function properly.
The immediate cause is obviously the SQLite behavior, but I'm
certain there's a lot more baggage hiding behind this multiple
Libpod runtime logic, so let's just refactor it out. It doesn't
make sense, and complicates the code. Instead, make Reset,
Renumber, and Migrate methods of the libpod Runtime. For Reset
and Renumber, we can shut the runtime down afterwards to achieve
the desired effect (no valid runtime after). Then pipe all of
them through the ContainerEngine so cmd/podman can access them.
As part of this, remove the SystemEngine part of pkg/domain. This
was supposed to encompass these "special" commands, but every
command in SystemEngine is actually a ContainerEngine command.
Reset, Renumber, Migrate - they all need a full Libpod and access
to all containers. There's no point to a separate engine if it
just wraps Libpod in the exact same way as ContainerEngine. This
consolidation saves us a bit more code and complexity.
Signed-off-by: Matt Heon <mheon@redhat.com>
<MH: Fixed cherry-pick conflicts for v4.8 branch>
Signed-off-by: Matt Heon <mheon@redhat.com>
It looks like we had some logic for this from #10789 but it does
not appear to have ever worked; we can't pull external containers
out of the DB, so the ContainerRm call failed unconditionally.
Instead, just handle them in Libpod when we're removing images.
We're removing every image, so setting Force when removing images
should get rid of all external containers. It's a little later in
the process than the current (nonfunctional) solution is but I
can't think of a reason why that would be bad.
[NO NEW TESTS NEEDED] We do not currently test `system reset`.
We should probably reevaluate that at some point this year.
Fixes https://issues.redhat.com/browse/RHEL-21261
Signed-off-by: Matt Heon <mheon@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.
Picked from main 48ab4aec31.
Partially addresses: https://issues.redhat.com/browse/RHEL-21422
[NO NEW TESTS NEEDED]
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
fix https://github.com/containers/podman-desktop/issues/5282
With FCOS we have a limit of 2048 files
But when launching containers like kind containers, we're reaching
easily the limit.
AFAIK as it's inside a dedicated machine, limit should be max
Limit should be only at the container level.
Signed-off-by: Florent Benoit <fbenoit@redhat.com>
