When InitialDelaySeconds in the kube yaml is set for a helthcheck,
don't update the healthcheck status till those initial delay seconds are over.
We were waiting to update for a failing healtcheck, but when the healthcheck
was successful during the initial delay time, the status was being updated as healthy
immediately.
This is misleading to the users wondering why their healthcheck takes
much longer to fail for a failing case while it is quick to succeed for
a healthy case. It also doesn't match what the k8s InitialDelaySeconds
does. This change is only for kube play, podman healthcheck run is
unaffected.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
SSH uses 22 as default so it is really not necessary to require the
port. The backend code already does this but the parsing in the
frontend always tried to parse the port.
[NO NEW TESTS NEEDED] This would require actual remote host ssh setup in
CI so it is not possible to be check but I verified it locally.
Fixes https://issues.redhat.com/browse/RHEL-17776
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When committing containers to create new images, accept a container
config blob being passed in the body of the API request by adding a
Config field to our API structures. Populate it from the body of
requests that we receive, and use its contents as the body of requests
that we make.
Make the libpod commit endpoint split changes values at newlines, just
like the compat endpoint does.
Pass both the config blob and the "changes" slice to buildah's Commit()
API, so that it can handle cases where they overlap or conflict.
Signed-off-by: Nalin Dahyabhai <nalin@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>
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>
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>
Provides Docker API client access, allowing compose to work by default
for HyperV. Basically the HyperV equiv of the work done here by #12916.
[NO NEW TESTS NEEDED]
Signed-off-by: Ashley Cui <acui@redhat.com>
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>
Add test for a specific crash
Update play build test to expect message in stderr
Signed-off-by: Ygal Blum <ygal.blum@gmail.com>
(cherry picked from commit a943be7e8e)
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Previously the WSL user-mode networking distribution was only installed as part
of a change, when it should have been also applied installs. This mean that the
init flag usage only worked after a previous set command.
[NO NEW TESTS NEEDED]
Signed-off-by: Jason T. Greene <jason.greene@redhat.com>
When a new API call is added to the bindings we should guard it based on
the version and throw a useful error. Right now an old server that does
not implement a given endpoint would throw a "NOT FOUND" error which is
not good for callers.
Instead implement a custom error type to give a usefule error instead.
This allows bindings users to call errors.As() to know if they call and
to old version.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Commit f48a706abc added a new API endpoint to remove exec session
correctly. And the bindings try to call that endpoint for exec every
time. Now since client and server must not be the same version this
causes a problem if a new 4.8 client calls an older 4.7 server as it has
no idea about such endpoint and throws an ugly error. This is a common
scenario for podman machine setups.
The client does know the server version so it should make sure to not
call such endpoint if the server is older than 4.8.
I added a exec test to the machine tests as this can be reproduced with
podman machine as at the moment at least the VM image does not contain
podman 4.8. And it should at least make sure podman exec keeps working
for podman machine without regressions.
Fixes#20821
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Fixed a bug where `podman machine rm -f` would cause a deadlock when
running with WSL.
The deadlock is caused by the Remove() function calling the Stop()
function after Remove() locks the VM. Stop() also has a lock call, which
fails and deadlocks because Remove() already claimed lock. Fix this by
moving the stop call before the lock
[NO NEW TESTS NEEDED]
Signed-off-by: Ashley Cui <acui@redhat.com>
Currently if user specifies podman kube play --replace, the
pod is removed on the client side, not the server side. If
the API is called with replace=true, the pod was not being removed
and this called the API to fail. This PR removes the pod if it
exists and the caller specifies replace=true.
Fixes: https://github.com/containers/podman/discussions/20705
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
If gvproxy or vfkit exit we can error right away, so while we wait for
the socket to get ready we also keep checking the process status with
wait4() and WNOHANG so it does not block forever.
This is completely untested as I do not have acces to apple machine.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
<MH: Added no new tests needed to pass CI>
[NO NEW TESTS NEEDED]
Signed-off-by: Matt Heon <mheon@redhat.com>
florent found a bug where he used "applehv" as a machine name. it turns out when we use a vmtype name, esp. the active type, it really messes up directory structures for configuration and images alike.
Signed-off-by: Brent Baude <bbaude@redhat.com>
Support UIDMap, GIDMap, SubUIDMap and SubGIDMap
If any of them are set disregard the deprecated Remap keys
Add tests and man
Signed-off-by: Ygal Blum <ygal.blum@gmail.com>
