Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calling inspect with a {{json .}} template doesn't unwrap the object #16436

Closed
ValentinParamonov opened this issue Nov 7, 2022 · 4 comments · Fixed by containers/common#1226 or #16446
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@ValentinParamonov
Copy link

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Steps to reproduce the issue:

  1. Call podman inspect -f '{{json .}}' busybox

Describe the results you received:

A JSON array with a single object inside of it:

[
     {
          "Id": "bc01a3326866eedd68525a4d2d91d2cf86f9893db054601d6be524d5c9d03981",
          "Digest": "sha256:6bdd92bf5240be1b5f3bf71324f5e371fe59f0e153b27fa1f1620f78ba16963c",
          "RepoTags": [
               "docker.io/library/busybox:latest"
          ],
          "RepoDigests": [
               "docker.io/library/busybox@sha256:6bdd92bf5240be1b5f3bf71324f5e371fe59f0e153b27fa1f1620f78ba16963c",
               "docker.io/library/busybox@sha256:dacd1aa51e0b27c0e36c4981a7a8d9d8ec2c4a74bf125c0a44d0709497a522e9"
          ],
          "Parent": "",
          "Comment": "",
          "Created": "2022-10-26T06:30:33.794221299Z",
          "Config": {
               "Env": [
                    "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
               ],
               "Cmd": [
                    "sh"
               ]
          },
          "Version": "20.10.12",
          "Author": "",
          "Architecture": "amd64",
          "Os": "linux",
          "Size": 1464006,
          "VirtualSize": 1464006,
          "GraphDriver": {
               "Name": "overlay",
               "Data": {
                    "UpperDir": "/home/valentine/.local/share/containers/storage/overlay/0438ade5aeea533b00cd75095bec75fbc2b307bace4c89bb39b75d428637bcd8/diff",
                    "WorkDir": "/home/valentine/.local/share/containers/storage/overlay/0438ade5aeea533b00cd75095bec75fbc2b307bace4c89bb39b75d428637bcd8/work"
               }
          },
          "RootFS": {
               "Type": "layers",
               "Layers": [
                    "sha256:0438ade5aeea533b00cd75095bec75fbc2b307bace4c89bb39b75d428637bcd8"
               ]
          },
          "Labels": null,
          "Annotations": {},
          "ManifestType": "application/vnd.docker.distribution.manifest.v2+json",
          "User": "",
          "History": [
               {
                    "created": "2022-10-26T06:30:33.700079457Z",
                    "created_by": "/bin/sh -c #(nop) ADD file:5e991de3200129dc05c3130f7a64bebb5704486b4f773bfcaa6b13165d6c2416 in / "
               },
               {
                    "created": "2022-10-26T06:30:33.794221299Z",
                    "created_by": "/bin/sh -c #(nop)  CMD [\"sh\"]",
                    "empty_layer": true
               }
          ],
          "NamesHistory": [
               "docker.io/library/busybox:latest"
          ]
     }
]

Describe the results you expected:

I'd expect the output to be the same as docker's (not sure about the formatting, but the object should be unwrapped):

docker inspect -f '{{json .}}' busybox

produces

{"Id":"sha256:bc01a3326866eedd68525a4d2d91d2cf86f9893db054601d6be524d5c9d03981","RepoTags":["busybox:latest"],"RepoDigests":["busybox@sha256:6bdd92bf5240be1b5f3bf71324f5e371fe59f0e153b27fa1f1620f78ba16963c"],"Parent":"","Comment":"","Created":"2022-10-26T06:30:33.794221299Z","Container":"773c16077d49e716d62d584e90b21a0c0d5807680177b879bf28b6a1f997966c","ContainerConfig":{"Hostname":"773c16077d49","Domainname":"","User":"","AttachStdin":false,"AttachStdout":false,"AttachStderr":false,"Tty":false,"OpenStdin":false,"StdinOnce":false,"Env":["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"],"Cmd":["/bin/sh","-c","#(nop) ","CMD [\"sh\"]"],"Image":"sha256:bd903b2b2a1001a80d9d50f9c3d77c648184cc89bdb622b84d59790ff6ee1f40","Volumes":null,"WorkingDir":"","Entrypoint":null,"OnBuild":null,"Labels":{}},"DockerVersion":"20.10.12","Author":"","Config":{"Hostname":"","Domainname":"","User":"","AttachStdin":false,"AttachStdout":false,"AttachStderr":false,"Tty":false,"OpenStdin":false,"StdinOnce":false,"Env":["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"],"Cmd":["sh"],"Image":"sha256:bd903b2b2a1001a80d9d50f9c3d77c648184cc89bdb622b84d59790ff6ee1f40","Volumes":null,"WorkingDir":"","Entrypoint":null,"OnBuild":null,"Labels":null},"Architecture":"amd64","Os":"linux","Size":1239772,"VirtualSize":1239772,"GraphDriver":{"Data":{"MergedDir":"/home/valentine/.docker/volumes/overlay2/6821b031fdaa32d2ebcb280213baab919f7e179d36fc4f8bb309ef46971f7102/merged","UpperDir":"/home/valentine/.docker/volumes/overlay2/6821b031fdaa32d2ebcb280213baab919f7e179d36fc4f8bb309ef46971f7102/diff","WorkDir":"/home/valentine/.docker/volumes/overlay2/6821b031fdaa32d2ebcb280213baab919f7e179d36fc4f8bb309ef46971f7102/work"},"Name":"overlay2"},"RootFS":{"Type":"layers","Layers":["sha256:0438ade5aeea533b00cd75095bec75fbc2b307bace4c89bb39b75d428637bcd8"]},"Metadata":{"LastTagTime":"0001-01-01T00:00:00Z"}}

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Client:       Podman Engine
Version:      4.3.0
API Version:  4.3.0
Go Version:   go1.19.2
Git Commit:   ad42af94903ce4f3c3cd0693e4e17e4286bf094b-dirty
Built:        Thu Oct 20 00:09:30 2022
OS/Arch:      linux/amd64

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.28.0
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: /usr/bin/conmon is owned by conmon 1:2.1.5-1
    path: /usr/bin/conmon
    version: 'conmon version 2.1.5, commit: c9f7f19eb82d5b8151fc3ba7fbbccf03fdcd0325'
  cpuUtilization:
    idlePercent: 96.93
    systemPercent: 0.43
    userPercent: 2.64
  cpus: 16
  distribution:
    distribution: arch
    version: unknown
  eventLogger: journald
  hostname: kame
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.0.7-arch1-1
  linkmode: dynamic
  logDriver: journald
  memFree: 26904285184
  memTotal: 67123310592
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: /usr/bin/crun is owned by crun 1.6-1
    path: /usr/bin/crun
    version: |-
      crun version 1.6
      commit: 18cf2efbb8feb2b2f20e316520e0fd0b6c41ef4d
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1001/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /etc/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: /usr/bin/slirp4netns is owned by slirp4netns 1.2.0-1
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.4
  swapFree: 68719472640
  swapTotal: 68719472640
  uptime: 11h 35m 41.00s (Approximately 0.46 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/valentine/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/valentine/.local/share/containers/storage
  graphRootAllocated: 442297745408
  graphRootUsed: 153486311424
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 49
  runRoot: /run/user/1001/containers
  volumePath: /home/valentine/.local/share/containers/storage/volumes
version:
  APIVersion: 4.3.0
  Built: 1666213770
  BuiltTime: Thu Oct 20 00:09:30 2022
  GitCommit: ad42af94903ce4f3c3cd0693e4e17e4286bf094b-dirty
  GoVersion: go1.19.2
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.0

Package info (pacman -Q podman):

podman 4.3.0-1

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Yes

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Nov 7, 2022
@ValentinParamonov
Copy link
Author

Basically, {{json .}} should be treated the same way as {{. | json}}.

@Luap99
Copy link
Member

Luap99 commented Nov 8, 2022

Yes currently {{json .}} is considered the same as json. As you noted this is not correct when the output is an array.
I take a look.

@Luap99 Luap99 self-assigned this Nov 8, 2022
Luap99 added a commit to Luap99/common that referenced this issue Nov 8, 2022
When a user request --format `{{json .}}` they would want the go
template parser to handle it. Currently we overwrite this and assume
that `{{json .}}` equals `json`. This is not correct. When the output is
a range (array), i.e. podman ps, it should return one json object per
line and not a json array which is the case with `json`.

This is required for docker compat.

Fixes containers/podman#16436

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
@Luap99 Luap99 reopened this Nov 8, 2022
Luap99 added a commit to Luap99/libpod that referenced this issue Nov 9, 2022
`--format json` should not be the same as `--format {{json .}}`, the
later should actually run through the go template and thus create one
json object per entry instead of an json array.

Includes a vendor of c/common@main since it requires a fix from there as
well.

This matches docker compat.
Fixes containers#16436

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
@frippe75
Copy link

frippe75 commented Feb 5, 2023

Should I open a new issue or add to this?

The fix may have addressed the reported issue. But taking it a step further the podman-inspect man pages clearly have a few examples where using a JSON path type of a query allows limiting the out to what you really need.

$ docker network inspect -f '{{ json . }}' kind
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
[
     {
          "name": "kind",
          "id": "751e7c3199a91d12c23af8d0a2ae1b710896259f8ff8e40515f3687431492919",
          "driver": "bridge",
          "network_interface": "podman1",
          "created": "2023-02-04T15:43:58.694036133+01:00",
          "subnets": [
               {
                    "subnet": "fc00:f853:ccd:e793::/64",
                    "gateway": "fc00:f853:ccd:e793::1"
               },
               {
                    "subnet": "10.89.0.0/24",
                    "gateway": "10.89.0.1"
               }
          ],
          "ipv6_enabled": true,
          "internal": false,
          "dns_enabled": true,
          "ipam_options": {
               "driver": "host-local"
          }
     }
]

I am then trying to target the name field.

$ docker network inspect -f '{{ json .name }}' kind
Error: inspecting object: printing inspect output: template: inspect:1:19: executing "inspect" at <.name>: can't evaluate field name in type interface {}

Running a similar command on a non podman host

docker inspect -f '{{ json . }}' host
{"Name":"host","Id":"08dccc8f8f27039b95a6e7bfa7611ac3590f5992e8637625249d1e772549cf64","Created":"2022-11-25T21:10:47.039558663+01:00","Scope":"local","Driver":"host","EnableIPv6":false,"IPAM":{"Driver":"default","Options":null,"Config":[]},"Internal":false,"Attachable":false,"Ingress":false,"ConfigFrom":{"Network":""},"ConfigOnly":false,"Containers":{},"Options":{},"Labels":{}}

Docker is not returning the output as an array of a single object with a document in that first element. Just a JSON doc, nothing more.

Targeting the "Name" works as expectred.

$ docker inspect -f '{{ json .Name }}' host
"host"

@rhatdan
Copy link
Member

rhatdan commented Feb 8, 2023

Yes new issue.

libvirtmirror pushed a commit to libvirt/libvirt-ci that referenced this issue Feb 23, 2023
The '{{ json . }}' syntax has returned a single JSON
document with an array of entries for images historically
with podman.

Since podman 4.4.0 this now returns a concatenation of
JSON documents, one document per image. Our code is not
able to parse a concatenation of documents.

This was done to fix docker compatibility[1], because

  {{ json .}}

was supposed to be equivalent to

  {{ . | json }}

while podman mistakenly made it equivalent to

  {{ json }}

IOW, we were already broken in terms of docker compat
too.

Since we want the single document, we need to use plain
'json' or '{{ json }}'. This picks the former since it
does not appear we have a need to use any advanced
features of the Go template syntax.

[1] containers/podman#16436
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 1, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 1, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
4 participants