The other direction: fix or clean up elements documented in
man pages but which did/do not exist in actual podman:
* runlabel: add missing "-n" alias for --name
And, remove man page entries for nonexistent options:
* podman commit: --iidfile
* podman container runlabel: --rootfs, --storage
* podman create: --cpu-count
There are two problems I don't know how to deal with. Both
are related to main_local.go:rootCmd.PersistentFlags() :
1) podman-build.1.md documents --cni-config-dir and
--runtime options, but these are not actually options
under podman build; they are global options. The
documentation in this man page differs from that
under podman-build.
2) podman ps implements a binary --namespace option,
but this option does not (cannot?) appear in --help
because there's a global --namespace string option
and Cobra somehow gets confused about this.
Do we really intend for global options to be parsed on
the right-hand side of subcommands? This strikes me as
unintuitive and potentially confusing, although the
fact that it has taken me this long to discover it
suggests that it's not _that_ confusing.
Suggestions welcome. I can file issues for 1/2 above,
or simply teach my script to special-case ignore them.
Signed-off-by: Ed Santiago <santiago@redhat.com>
I wrote a script to cross-reference podman --help against
man pages. It found a bunch of inconsistencies fix them:
* options missing from man pages
* options misspelled or misformatted in man pages (usually
misplaced asterisks or missing dashes, but see --dns-opt)
* one spurious comma in the actual source file --help
This is a fix in which I iterate over 'podman CMD --help'
and check for presence in man pages. The other way around
(look for flags in man pages, check podman CMD --help)
is probably impossible: there are too many special cases
Signed-off-by: Ed Santiago <santiago@redhat.com>
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>
OpenShift Merge Robot
Ed Santiago
Matthew Heon
Brent Baude
Sujil02
Valentin Rothberg
Jhon Honce
Clint Olson
Matthew Heon
Carlos Panato
dependabot-preview[bot]
Daniel J Walsh