Buildah unable to push built images to Dockerhub

[johnmcollier]

Description
Ever since yesterday, I've been unable to push large (~ 30MB or greater) images to dockerhub using buildah 1.10. I can push the super-tiny hello-world image without issue, but anything bigger fails. What's even weird is that buildah doesn't report any errors, and the exit code is 0, but no image gets pushed to my dockerhub account.

Using the same buildah binary, I can push fine to my own internal OKD registry. Perhaps an API change in dockerhub occurred??

Steps to reproduce the issue:

1. Install buildah
2. Pull down the johncollier/cw-springproj-271f59b0-9773-11e9-ba26 image: buildah pull johncollier/cw-springproj-271f59b0-9773-11e9-ba26
3. Try to push that image to Dockerhub. Buildah will report no errors, but no image will have actually been pushed and nothing will show up on the dockerhub account

Describe the results you received:
Buildah couldn't push images to dockerhub

Describe the results you expected:
Buildah can push the image to dockerhub fine

Output of rpm -q buildah or apt list buildah:

sh-4.2# rpm -q buildah
buildah-1.10.1-2.git8c1c2c5.fc30.x86_64

Output of buildah version:

sh-4.2# buildah version
Version:         1.10.1
Go Version:      go1.12.7
Image Spec:      1.0.1
Runtime Spec:    1.0.1-dev
CNI Spec:        0.4.0
libcni Version:  
Git Commit:      
Built:           Thu Jan  1 00:00:00 1970
OS/Arch:         linux/amd64

Output of cat /etc/*release:

sh-4.2# cat /etc/*release
CentOS Linux release 7.6.1810 (Core) 
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.6.1810 (Core) 
CentOS Linux release 7.6.1810 (Core) 

Output of uname -a:

Linux codewind-workspacepnijvwrudezx2f90-7d57775b75-x9plq 3.10.0-1062.el7.x86_64 #1 SMP Thu Jul 18 20:25:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Output of cat /etc/containers/storage.conf:

sh-4.2# cat /etc/containers/storage.conf
# storage.conf is the configuration file for all tools
# that share the containers/storage libraries
# See man 5 containers-storage.conf for more information
# The "container storage" table contains all of the server options.
[storage]

# Default Storage Driver
driver = "overlay"

# Temporary storage location
runroot = "/var/run/containers/storage"

# Primary Read/Write location of container storage
graphroot = "/var/lib/containers/storage"

[storage.options]
# Storage options to be passed to underlying storage drivers

# AdditionalImageStores is used to pass paths to additional Read/Only image stores
# Must be comma separated list.
additionalimagestores = [
]

# Size is used to set a maximum size of the container image.  Only supported by
# certain container storage drivers.
size = ""

# OverrideKernelCheck tells the driver to ignore kernel checks based on kernel version
override_kernel_check = "true"

# Remap-UIDs/GIDs is the mapping from UIDs/GIDs as they should appear inside of
# a container, to UIDs/GIDs as they should appear outside of the container, and
# the length of the range of UIDs/GIDs.  Additional mapped sets can be listed
# and will be heeded by libraries, but there are limits to the number of
# mappings which the kernel will allow when you later attempt to run a
# container.
#
# remap-uids = 0:1668442479:65536
# remap-gids = 0:1668442479:65536

# Remap-User/Group is a name which can be used to look up one or more UID/GID
# ranges in the /etc/subuid or /etc/subgid file.  Mappings are set up starting
# with an in-container ID of 0 and the a host-level ID taken from the lowest
# range that matches the specified name, and using the length of that range.
# Additional ranges are then assigned, using the ranges which specify the
# lowest host-level IDs first, to the lowest not-yet-mapped container-level ID,
# until all of the entries have been used for maps.
#
# remap-user = "storage"
# remap-group = "storage"

[storage.options.thinpool]
# Storage Options for thinpool

# autoextend_percent determines the amount by which pool needs to be
# grown. This is specified in terms of % of pool size. So a value of 20 means
# that when threshold is hit, pool will be grown by 20% of existing
# pool size.
# autoextend_percent = "20"

# autoextend_threshold determines the pool extension threshold in terms
# of percentage of pool size. For example, if threshold is 60, that means when
# pool is 60% full, threshold has been hit.
# autoextend_threshold = "80"

# basesize specifies the size to use when creating the base device, which
# limits the size of images and containers.
# basesize = "10G"

# blocksize specifies a custom blocksize to use for the thin pool.
# blocksize="64k"

# directlvm_device specifies a custom block storage device to use for the
# thin pool. Required if you setup devicemapper
# directlvm_device = ""

# directlvm_device_force wipes device even if device already has a filesystem
# directlvm_device_force = "True"

# fs specifies the filesystem type to use for the base device.
# fs="xfs"

# log_level sets the log level of devicemapper.
# 0: LogLevelSuppress 0 (Default)
# 2: LogLevelFatal
# 3: LogLevelErr
# 4: LogLevelWarn
# 5: LogLevelNotice
# 6: LogLevelInfo
# 7: LogLevelDebug
# log_level = "7"

# min_free_space specifies the min free space percent in a thin pool require for
# new device creation to succeed. Valid values are from 0% - 99%.
# Value 0% disables
# min_free_space = "10%"

# mkfsarg specifies extra mkfs arguments to be used when creating the base
# device.
# mkfsarg = ""

# mountopt specifies extra mount options used when mounting the thin devices.
# mountopt = ""

# use_deferred_removal Marking device for deferred removal
# use_deferred_removal = "True"

# use_deferred_deletion Marking device for deferred deletion
# use_deferred_deletion = "True"

# xfs_nospace_max_retries specifies the maximum number of retries XFS should
# attempt to complete IO when ENOSPC (no space) error is returned by
# underlying storage device.
# xfs_nospace_max_retries = "0"

[johnmcollier]

I should note that before yesterday, I had no issues pushing to dockerhub with the exact same version of buildah.

[rhatdan]

@vrothberg @mtrmac PTAL

[mtrmac]

What does buildah --debug … say about the push?

[johnmcollier]

@mtrmac Here are the logs from it: buildah_debug.txt

There's nothing suspect in it, and it also says the push was successful. But the image doesn't show up on my dockerhub account.

However: I can pull it with buildah pull johncollier/spring-push-test), but I cannot pull it using docker (either with the CLI or with Kubernetes/OKD):

johns-mbp-3:~ johncollier$ docker pull johncollier/spring-push-test
Using default tag: latest
Error response from daemon: mediaType in manifest should be 'application/vnd.docker.distribution.manifest.v2+json' not ''

Seems like it's expecting some some mediaType field in some manifest file?

[mtrmac]

Thanks. The registry accepts an OCI-formatted manifest; and if buildah pull can read it, then the registry can also return the data.

It’s then, “only” the UI and Docker, that can’t deal with the OCI-formatted manifest.

[johnmcollier]

@mtrmac I changed the title to mention images built using buildah bud.

If I build an image using buildah bud and try to push it to dockerhub, I'll hit this issue I'm seeing where it doesn't show up.

If I push a prebuilt image, it pushes fine and shows up on dockerhub (assuming the manifest is as dockerhub expects it).

[rhatdan]

What happens if you build it with --format docker? Does the push succeed and show up then?

[mtrmac]

Sure; pre-existing images are likely to use Docker schema2, and will be pushed using the same format.

New images are created using OCI by default (and converted to schema2 if the destination registry does not support OCI). But of course, the registry supporting OCI does not indicate that any other future consumer, like the UI or /usr/bin/docker, can support OCI as well.

--format docker should work around this.

[johnmcollier]

@mtrmac @rhatdan Thanks, that worked! Good to know about --format docker. This issue can be closed now.

Thanks a ton for your help!!

[rhatdan]

@johnmcollier Please report the issue to docker.io, that pushing OCI images to the registry, they don't show up in the UI.

[johnmcollier]

@rhatdan Will do

[johnmcollier]

@rhatdan @mtrmac I've opened docker/hub-feedback#1871, feel free to add more details to it if needed