Unqualified names with --all-tags always resolve via docker.io rather
than registries.conf search lists. Spell that out, and note that
--include-volumes only applies when set to true.
Fixes#23625Fixes#15387
Signed-off-by: Dean Chen <862469039@qq.com>
Support for these was removed in 3721ff82ff as the feature is
inherently insecure. Checkpoints imply an extremely privileged
operation that is incompatible with the constraints of a
`podman run` command. However, we should still tell folks that
it no longer works with a clear error message. This is done
during Specgen processing, server side, which should be safer
than the previous client-side processing for these.
Signed-off-by: Matt Heon <matthew.heon@pm.me>
Add an example to podman-container-inspect(1) demonstrating how to query whether a container is an init container and check its type using --format.
Follow-up to #29818.
Signed-off-by: Malhar Jivrajani <mjivraja@redhat.com>
Allow deployments and scheduled jobs to update a selected group of
containers without checking every auto-update-enabled application.
Reuse the existing container filters and expose them through the CLI,
remote bindings, and REST API.
Filter update candidates while preserving systemd unit and pod restart
behavior. Document the selection semantics and cover filtered updates,
invalid input, remote requests, and pod restarts in the existing tests.
Signed-off-by: Evan Purkhiser <git@evanpurkhiser.com>
Podman 6 dropped cgroups v1 support, and the kernel real-time
scheduler cgroup settings only exist on cgroups v1. That means the
--cpu-rt-period and --cpu-rt-runtime options can never take effect
anymore: on cgroups v2 the values only produce a warning and are
discarded.
As agreed in the linked issue, the full removal of the options is
deferred to the next major release (7.0) to avoid a breaking change
for anyone still setting them. For 6.x this commit implements the
agreed interim step:
- remove the option documentation (docs/source/markdown/options/
cpu-rt-period.md and cpu-rt-runtime.md) and drop the @@option
references from the podman-create, podman-run, podman-update and
podman-container-clone man pages
- hide both flags from --help output
- change the existing warning to state that the option is a NOP,
that the value is ignored, and that the option will be removed in
the next major release
The e2e tests are updated to match the new warning text. Actual
removal of the flags and the spec fields is left for Podman 7.0.
Part of #29750
Signed-off-by: seonghun lee <harrisleesh@gmail.com>
The value given to --ulimit is passed to the container unchanged and is
interpreted by setrlimit(2), so size limits such as memlock are in bytes.
The ulimit shell builtin scales most of those values when printing them
(kbytes for -d, -l, -m, -s, 512-byte blocks for -c, -f), which makes the
value reported inside the container look wrong.
Document the unit used by each limit type, add an example, and note that
unit suffixes are not accepted. No behavior change.
Fixes: #25236
Signed-off-by: i-OmSharma <sharmaom1201@gmail.com>
podman events --filter network=<name> was unconditionally returning
'NETWORK is an invalid filter' because the NETWORK case was absent
from the generateEventFilter switch statement in filters.go.
All other first-class event types (container, image, pod, volume)
had corresponding filter cases, but the Network type - despite being
fully defined in config.go along with NetworkConnect/NetworkDisconnect
statuses and the Event.Network field - had no handler.
Add the NETWORK case to filter by network name (e.Network), consistent
with Docker's --filter network= behaviour. ID-prefix matching is
intentionally omitted: for network connect/disconnect events e.ID
holds the container ID, not the network ID, so prefix matching would
only work for create/remove events and silently miss join/leave events.
Also add unit tests (filters_test.go), integration tests
(test/e2e/events_test.go, test/system/090-events.bats), shell
completion support for --filter network= (completion.go), and
document the new filter key in the man page.
Fixes: https://github.com/podman-container-tools/podman/issues/29387
Signed-off-by: Aftab Ali <aftab123215@gmail.com>
Until now the default could only be expressed by leaving the option off, which
reads as an omission rather than a choice and gives a script no way to say it
wants the archive transferred as podman save wrote it.
Accept none as a format meaning exactly that. It is taken on the API path too,
so both interfaces share one vocabulary, and it is treated as the absence of a
format throughout: nothing is compressed, a level attached to it is rejected the
same way a level with no format is, and the local user to user transfer has
nothing to warn about ignoring.
The remote client still leaves it off the request, so naming the default does
not make a transfer fail against a service that predates these options.
Signed-off-by: Scott Callaway <github@scottcallaway.co.uk>
Built as a general podman machine custom OS tutorial but using the
architectures use case as an example.
Related to #29688
Signed-off-by: Jason Frey <fryguy9@gmail.com>
Expose the compression the transfer already knows how to do, and document what
each option means on each path.
--compression-format takes gzip or zstd, matching the vocabulary
--compression-format already uses on podman push, minus the algorithms this
cannot produce or detect. --compression-level takes the level, and is rejected
without a format to apply it to rather than being silently ignored.
The level needs one caveat spelling out in the man page. A remote source passes
it to the command line compressor, where every value is distinct. A local source
compresses through c/image, which groups zstd levels into four bands, so 10 and
above are the same there. The accepted zstd range also stops at 19 rather than
podman push's 20, because the command line compressor needs --ultra past that.
The flags are validated before the engine is reached, so podman --remote reports
a bad combination without a round trip; the transfer validates again for callers
arriving over the API.
Fixes: #23192
Signed-off-by: Scott Callaway <github@scottcallaway.co.uk>
Do not set RemainAfterExit=yes by default when converting Quadlet
.volume files to systemd oneshot services.
Setting RemainAfterExit=yes causes systemd to consider the volume
service active even after the volume is deleted manually, preventing
systemd from re-executing volume creation when dependent container
services restart.
Fixes#27862
Signed-off-by: Sachin Mahajan <sachinmahajan903@gmail.com>
When pushing a manifest list, --platform=OS[/Arch[/Variant]] selects and pushes a single platform-specific manifest instead of the entire list.
Also, update compat POST /images/{name}/push to support the platform param (Compat v1.46)
Signed-off-by: Ashley Cui <acui@redhat.com>
Problem: podman artifact ls has no way to print just artifact
identifiers. Scripts that want to act on artifacts (e.g. remove them)
have to parse table output or use --format {{.Digest}}. Every other
listing command in podman (images, ps, artifact push/pull) already
supports -q/--quiet for this.
Impact: users can now run `podman artifact ls --quiet` to get one
digest per line, no header, suitable for piping into other podman
commands.
Change: adds a --quiet/-q bool flag to the list command. When set (and
--format is not also given), output.Digest is printed for each
artifact instead of the table.
Signed-off-by: umar11b <uzaman2018@gmail.com>
Several of the examples given for `podman manifest add` were missing the manifest name argument and one had a `sudo` prefix.
Signed-off-by: Jonathan Dowland <jdowland@redhat.com>
Document the default_host_ips option here to make it more visible. And
clarify the default v4/v6 bind behavior.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The 'podman artifact ls' command supports a --format flag accepting a go template string. Some commands (eg 'podman image ls') accept a --format=json parameter, and export pure json object to stdout.
This change adds a --format=json output mode to artifact lists too.
Includes simple documentation mention of --format=json option alongside go template description.
Signed-off-by: ellieayla <1447600+me@users.noreply.github.com>
podman farm build pushes each per-arch image to the registry by
appending `UnknownDigestSuffix` to the image specified using --tag. This
fails because a tag is not expected when UnknownDigestSuffix is used.
Parse the image reference and pass only the untagged image
reference when podman does this suffixed push to the registry.
Fixes#25039
Co-authored-by: Kevin Crocombe <kevin.crocombe@pegortech.co.uk>
Signed-off-by: Danish Prakash <contact@danishpraka.sh>
Remove hardcoded configuration file directory paths from podman.1.md and podman-image-trust.1.md.in. Instead of hardcoding paths that become outdated, direct readers to their respective man pages (such as containers.conf(5) and containers-policy.json(5)) for complete path resolution details.
Fixes: #29187
Signed-off-by: hihry <work.himanshu.r.v@gmail.com>
Signed-off-by: Himanshu Ravindra Iwanati <work.himanshu.r.v@gmail.com>
The farm command is helpful when it comes to building
multi-architecture container images, with a build out on various
different CPU architecture machines (e.g. amd64, arm64 etc). This
produces a multi-architecture image usable on many different kinds
of machines. Once those farms are built, we can list them out (ls)
in a human readable format.
Currently, podman farm list prints out every field (name,
connections, default, etc). The --quiet/-q flags cut the noise by
only printing the names of the farms, rather than all the other
farm list metadata.
The benefit of having this feature is for automation and scripts to
pull just the farm names from the list, which is mostly important
for CI pipelines to loop over.
Signed-off-by: umar11b <uzaman2018@gmail.com>
They are currently not shown anywhere so they provide no real value to
end users. They also have not been updated since they were added three
years ago.
Most users never update markdown.po but some did so that creates
unnecessary diffs on PRs for things that add no value.
To avoid that lets just remove them, as discussed at the community
meeting on Aug 13 2026. We are not against having translations again in
the future but it would need to have a proper process in place with
active people maintaining them and so that it shows up somewhere useful.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Dean Chen