Label feeding as null

[tthukral-NR-2]

Hi Team,

We manage synthetics monitor in New Relic and recently our product synthetics job manager when running in a private location using Podman has started seeing a change when upgrading from Podman version 5.4.0 to 5.6.0. Containers label was initially coming with some value whereas after the upgradation the label is feeding as null. We tried inspecting the scenario using claude which suggested below:

Environment

• Podman Version: 5.6.0
• OS: Red Hat Enterprise Linux (RHEL) 10.1
• Platform: linux/amd64
• Previous Working Version: 5.4.0
• Database Backend: sqlite (confirmed via podman info)

Steps to Reproduce

1. Create a pod with Podman 5.6.0:
   podman pod create --name test-pod
2. Inspect the infra container:
   podman ps -a --filter "name=infra"
   podman inspect | grep -A 2 '"Labels"'
3. Observe that "Labels": null instead of a map

Expected Behavior (Podman 5.4.0)

API Response:
{
"IsInfra": true,
"Image": "localhost/podman-pause:5.4.0-1757462400",
"ImageID": "e0611c37b940f510d90cd3fb0de3a08d19a3cf53297ee3a5cf0b8fc6aacb2882",
"Labels": {
"io.buildah.version": "1.39.4"
}
}

The infra container used a pause image and inherited labels from it.

Actual Behavior (Podman 5.6.0)

API Response:
{
"IsInfra": true,
"Image": "",
"ImageID": "",
"Labels": null,
"Rootfs": "/run/user/1000/libpod/tmp/infra-container"
}

Key differences:

• Labels is null (not an empty map)
• Image is empty string
• Rootfs points to a temporary location instead of using a pause image

CLI Output:
$ podman inspect | grep -A 2 '"Labels"'
"Labels": null,

Evidence Collected

All other container types still have labels:
$ podman ps -a --format "{{.Names}} | {{.Labels}}"
5e189b1655fe-infra | map[]
practical_poitras | map[application:synthetics-job-manager ...]
PING | map[DEPLOYMENT_MODE:PERSISTENT SERVICE:RUNTIME ...]
browser-runtime | map[DEPLOYMENT_MODE:EPHEMERAL SERVICE:RUNTIME ...]

Only the infra container has empty/null labels.

Questions

1. Is this change intentional? We could not find any mention of infra container changes in the https://github.com/containers/podman/releases/tag/v5.6.0.
2. Why was the pause image removed? The infra container now uses a temporary rootfs instead of a pause image. Is this theory correct?
3. Should applications expect null labels going forward?

We'd like to understand if this is the intended behaviour or a regression.

Additional Context

• The official Podman 5.6.0 release notes mention changes to Quadlet pod labels but nothing about infra container labels
• The changelog shows SQLite migration warnings but this doesn't appear to be a database issue since other containers retain their labels
• Both the REST API and CLI show the same null behavior, ruling out serialization bugs

Request

Could you please clarify:

1. Is this an intentional architectural change?
2. If so, could it be documented for future releases?
3. If not, should we expect a fix in an upcoming version?

Thank you for your help!

[Luap99]

Well the change to not use an image was intentional as it avoid extra overhead for the pause container.

The change of labels is a indirect consequence, generally in go json, we could either skip the Labels field completely (i.e. mark it as omitempty), show it as null when there are no labels initialized, or well the empty map of {} which then requires and extra allocation of a map in the go code as it is not the default nil value.

Practically speaking considering you reported this over 6 months after we released this it means no matter what we decide do now your tooling must be able to handle the null string in versions v5.6 -v5.8 at least.
And AFAICT this has less do with the infra image since rootfs containers can be created by users so you will hit the problem on even older version if you would use a rootfs container.

I don't think we have any strict rules API wise, there are plenty of values which could be either omitempty or null possibly if they are unset so it would be best if you json parser can handle that. i.e. just looking at Annotations it is the same thing.
I would not object a PR if someone wants to have Labels to be an explicit {} if there are none but otherwise I would not think it is worth it to fix this.