Update the strat and stop api to validate pod status based on status functions
rather than iterating over all the containers in the pod. (Addressing the TO-DO)
Signed-off-by: Sujil02 <sushah@redhat.com>
Update the outdated systemd and dbus dependencies which are now provided
as go modules. This will further tighten our dependencies and releases
and pave the way for the upcoming auto-update feature.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
While string variables are shown to expect a string argument, boolean
variables are not. This easily tricks users into believing they are
simple switches without arguments. Hence, explicitly mention the
default to clarify it a bit more.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Clarify in the man page that --syslog expexts an argument to prevent
users from believing it's a switch.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
This reverts commit d3d97a25e8.
This does not resolve the issues we expected it would, and has
some unexpected side effects with the upcoming exec rework.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
This reverts commit 4632b81c81.
We are reverting #5373 as well, which lays the foundation for
this commit, so it has to go as well.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
The example was not entirely correct. Users should use `podman generate
systemd` and use the output either directly or as a template for further
adjustments to their needs. Keeping an example in the rootless tutorial
is a maintenance burdon and can easily suggest incorrect usage patterns
to users.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
When enabling a systemd service we can specify which target will start
it by specifying it in the `[INSTALL]` section. In case of root, this
is commonly set to `multi-user.target` which is used to start other
essential system services such as the network manager, D-BUS and more.
However, the `multi-user.target` is not enough on all systems,
especially when running rootless and enabling user services. Multiple
users have reported issues that there isn't even an attempt to start the
service.
Setting the INSTALL target to `default.target` will fix the rootless
case. However, `default.target` may vary among systems. Fedora
Workstation, for instance, sets the `default.target` to the graphical
target (i.e., runlevel 5) while Fedora Server sets it to
`multi-user.target` which is on runlevel 2 and hence way earlier in the
startup sequence.
As INSTALL allows for specifying multiple INSTALL targets, we can set it
to `multi-user.target` to continue supporting existing workloads AND to
`default.target` which MAY redundantly attempt to start it at a later point;
effectively a NOP for the root case and essential for rootless.
Fixes: #5423
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
during container creation, if no network is provided, we need to add a default value so the container can be later started.
use apiv2 container creation for RunTopContainer instead of an exec to the system podman. RunTopContainer now also returns the container id and an error.
added a libpod commit endpoint.
also, changed the use of the connections and bindings slightly to make it more convenient to write tests.
Fixes: 5366
Signed-off-by: Brent Baude <bbaude@redhat.com>
Let's try to shorten up fedora-31-libpod-123456789etc to
just fedora-31.
While we're at it, shorten the window/darwin names too
Many many thanks to @fkorotkov for the suggestion to use 'alias'
Signed-off-by: Ed Santiago <santiago@redhat.com>
Basically, add a 'name' tag (remote, local) to each incantation
of TEST_REMOTE_CLIENT: true/false
I have no idea if this will work or what results it'll produce.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Specifically to get:
https://github.com/containernetworking/cni/pull/735
6f29b0165883b2b52ccd4dcb937162ea4c86927b intercept netplugin std err
But also pulls in some interface name validation and a compatibility
fix for configurations that don't set a CNI version.
Signed-off-by: Dan Williams <dcbw@redhat.com>
