Healthcheck not tracked on images

[AstraLuma]

/kind feature

Description

Looking at podman image inspect, the varlink IDL, and python-podman, I can see that containers have a healthcheck, but it is not tracked on the image.

Note that I have been consulting https://github.com/containers/libpod/blob/master/cmd/podman/varlink/io.podman.varlink this entire time, so I'm reasonably confident this issue exists in master.

Steps to reproduce the issue:

1. Create an image with a healthcheck (such as from a Dockerfile with a HEALTHCHECK line) with podman
2. Inspect it with podman

Describe the results you received:
No mention of a healthcheck anywhere in the image metadata

Describe the results you expected:
A mention in the healthcheck (probably in the Config section)

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

Output of podman version:

Version:            1.6.4
RemoteAPI Version:  1
Go Version:         go1.13.5
Git Commit:         5cc92849f7fc9dd734ca2fd8f3ae8830b9a7eb26
Built:              Sat Dec 21 13:13:24 2019
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: 5cc92849f7fc9dd734ca2fd8f3ae8830b9a7eb26
  go version: go1.13.5
  podman version: 1.6.4
host:
  BuildahVersion: 1.12.0-dev
  CgroupVersion: v1
  Conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.2, commit: unknown'
  Distribution:
    distribution: debian
    version: unknown
  IDMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  MemFree: 842928128
  MemTotal: 8229838848
  OCIRuntime:
    name: runc
    package: 'runc: /usr/sbin/runc'
    path: /usr/sbin/runc
    version: |-
      runc version 1.0.0~rc9+dfsg1
      commit: 1.0.0~rc9+dfsg1-1
      spec: 1.0.1-dev
  SwapFree: 6711959552
  SwapTotal: 8467247104
  arch: amd64
  cpus: 4
  eventlogger: journald
  hostname: cayde7
  kernel: 5.3.0-3-amd64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: 'slirp4netns: /usr/bin/slirp4netns'
    Version: |-
      slirp4netns version 0.4.1
      commit: 4d38845e2e311b684fc8d1c775c725bfcd5ddc27
  uptime: 51h 22m 42.62s (Approximately 2.12 days)
registries:
  blocked: null
  insecure: null
  search:
  - docker.io
store:
  ConfigFile: /home/astraluma/.config/containers/storage.conf
  ContainerStore:
    number: 70
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: 'fuse-overlayfs: /usr/bin/fuse-overlayfs'
      Version: |-
        fusermount3 version: 3.7.0
        fuse-overlayfs: version 0.7.2
        FUSE library version 3.7.0
        using FUSE kernel interface version 7.31
  GraphRoot: /home/astraluma/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 100
  RunRoot: /run/user/1000
  VolumePath: /home/astraluma/.local/share/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):

Ummm... complicated. Custom compile, partially using unreleased and semi-released debian packages.

[baude]

what kind of image are you making? oci or otherwise?

[AstraLuma]

Just default, which is oci.

[mheon]

I don't believe OCI containers support healthchecks - that's only supported with Docker-formatted images. If we're not producing errors about that, it could well be a bug

…

On Tue, Jan 7, 2020 at 11:23 AM Jamie Bliss ***@***.***> wrote: Just default, which is oci. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4799>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCFO3VNBOWHX3Z5MTILQ4ST6VANCNFSM4KDJHNDA> .

[baude]

as @mheon said, oci images dont have healthchecks are part of the spec and they are thrown away during image generation. i dont know if that is a logged or not. if you want the image metadata to retain healthchecks, you must use docker format.

[AstraLuma]

Yeah, just confirmed, with the default build settings:

STEP 30: ENTRYPOINT ["/mc-server-runner", "-shell", "/bin/sh"]
7a8312f9408198434fe3940d691f24b2ae808bb988c429e84117a436e5c80f90
STEP 31: CMD ["/mc/launch"]
d5ba12a776229e263e1a67678ca76c59699f78c16d34b3c4c4ef6888156cc8d8
STEP 32: HEALTHCHECK --start-period=5m CMD ["status"]
STEP 33: COMMIT
baff549cdcee1a9f3a57b71ddb4464620a73f0f1784cf667276c9fc39abea694

[AstraLuma]

Also, it's still not exposed on docker format images. I tested this with:

1. Adding --format docker to the build invocation
2. Running podman inspect on the resulting image

A subset of the inspect output is:

        "Config": {
            "Env": [
                "PATH=/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "LANG=C.UTF-8",
                "JAVA_HOME=/usr/local/openjdk-8",
                "JAVA_VERSION=8u232",
                "JAVA_BASE_URL=https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u232-b09/OpenJDK8U-jre_",
                "JAVA_URL_VERSION=8u232b09"
            ],
            "Entrypoint": [
                "/mc-server-runner",
                "-shell",
                "/bin/sh"
            ],
            "Cmd": [
                "/mc/launch"
            ],
            "Volumes": {
                "/mc/banned-ips.json": {},
                "/mc/banned-players.json": {},
                "/mc/logs": {},
                "/mc/ops.json": {},
                "/mc/server.properties": {},
                "/mc/whitelist.json": {},
                "/mc/world": {}
            }
        },

[baude]

i guess the question is if it is not there OR we are not displaying it via inspect. @mheon would this be in the json in the filesystem?

[mheon]

I presume so? It'd be in the image metadata JSON blobs. We access those through c/image, so this could be a bug retrieving them from c/image (unlikely) or a display issue where we're not showing them despite them being added (possible, but also not very likely, I think).