podman-container-tools/podman

podman/cmd/podman/common/create.go Lines 758 to 772 in 7ea8b6c subgidnameFlagName := "subgidname" createFlags.StringVar( &cf.SubUIDName, subgidnameFlagName, "", "Name of range listed in /etc/subgid for use in user namespace", ) _ = cmd.RegisterFlagCompletionFunc(subgidnameFlagName, completion.AutocompleteSubgidName) subuidnameFlagName := "subuidname" createFlags.StringVar( &cf.SubGIDName, subuidnameFlagName, "",

Feature request description The podman system hyperv-prep --status command currently only outputs human-readable text, requiring tools to parse stdout to extract structured information. Adding support for --format=json (or --json) would enable programmatic consumption of this data Suggest potential solution Add a --format=json flag (or --json) to output structured data: podman system hyperv-prep --status --format=json { "isGroupMember": true, "hasRegistryEntries": false, "status": "notApplied" } Have you considered any alternatives? No response Additional context No response

With podman 6 we dropped cgroupv2 support but we never removed the --cpu-rt-period and --cpu-rt-runtime cli options. As documented they only work on a cgroupsv1 system. It does not make sense to have options that cannot work anymore since running on cgroupv1 returns a hard error. However currently the options only print a warning not a hard error, so technically removing them would break whoever set them since they only saw a warning before. podman/pkg/specgen/generate/validate_linux.go Lines 55 to 65 in f1b80e5 if s.ResourceLimits.CPU != nil { cpu := s.ResourceLimits.CPU if cpu.RealtimePeriod != nil { warnings = append(warnings, "Realtime period not supported on cgroups V2 systems") cpu.RealtimePeriod = nil

I've confirmed the fix in 5.8.0 for #27414 but it only fixes the issue for podman run, not podman exec. In the latter case, an empty string is treated as nothing and the default "C-p,C-q" is used instead of disabling the detach sequence.

Feature request description Podman's journald log driver does not support --log-opt labels= (or the quadlet equivalent LogOpt=labels=). Docker's journald driver supports this option, causing it to promote the specified container label key/value pairs as structured fields directly into each journal entry. In Podman, passing labels via LogOpt= is silently ignored. Suggest potential solution When a container is started with --log-opt labels=<key1> (or the equivalent in a quadlet), the journald log driver should read the specified label keys from the container's label set and write their values as structured fields into each journal message sent to the journald socket, matching Docker's behavior. Have you considered any alternatives? LogOpt=tag= can write a custom value into SYSLOG_IDENTIFIER, but this overwrites the container's display name and only accepts a single value, making it unusable for grouping containers that belong to multiple logical groups simultaneously (see Additional con