For future reference; there was some back-and-forth on the deprecation;

• The Container and ContainerConfig fields are set when committing a container to an image (docker commit)
• When doing so, relevant fields from the container's config are copied to the image config (a subset of that config is part of the OCI specification)
• The ContainerConfig is not part of the OCI config, and not used by other runtimes, such as containerd (they ignore the field)
• However, we currently preserve the field when pushing an image, which means we keep non-OCI fields in the image that's "unused", but also affects the digest

While the information can be considered somewhat useful (e.g. docker container commit mycontainer image:foo would keep information about the container that was committed in docekr image inspect image:foo), that information is of limited use.

Re-implementing that functionality with the containerd integration involves storing it as custom metadata, which also involves significant additional complexity for a niche use-case, so;

• for the graph-driver situation: on old API versions, continue setting the ContainerConfig field (but this can be an empty struct, as documented in the API spec (fields may be empty))
• when pushing images, we should not preserve this information
• for new API versions, we omit the fields entirely
• when using the containerd store, also omit the fields

On a side note, we also briefly discussed NOT supporting older API versions when using the containerd integration. i.e., continue the road we started with;

• daemon: raise default minimum API version to v1.24 #46887

And raise minimum supported API version with the containerd store enabled to only the last X API versions to reduce the amount of complexity for "brand new" code.