thoth-station / jupyternb-build-pipeline Goto Github PK

error pushing image "insights-configuration-files-analysis" to "docker://docker-registry.upshift.redhat.com/aicoe-notebooks/insights-configuration-files-analysis:latest": error copying layers and metadata from "containers-storage:[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.imagestore=/var/lib/shared,overlay.mount_program=/usr/bin/fuse-overlayfs,overlay.mountopt=nodev,fsync=0]localhost/insights-configuration-files-analysis:latest" to "docker://docker-registry.upshift.redhat.com/aicoe-notebooks/insights-configuration-files-analysis:latest": Error trying to reuse blob sha256:76e525e1b16d0a56473d529790d3f1696078799abf41357103298a09f744f0fe at destination: failed to read from destination repository aicoe-notebooks/insights-configuration-files-analysis: 500 (Internal Server Error)

Hi All,
Thanks for your input so far.  I have added responses in red below.

Maneesh Mehra (CVP):  Thanks for bringing this to the CVP team's attention. We currently use this registry to store our sanity tests image. I have opened https://projects.engineering.redhat.com/browse/CVP-1184 for the CVP team to work on this migration. Do you want to give us a sense of urgency on this ?
Ideally by the end of September 2020, and definitely by the end of December 2020.  

Mike Bonnet (ic3):  We have internal images that are not suitable for public repos. Is there a process for requesting private quay.io repos? Is there guidance about creating a new org, or using an existing one? Note that the current "redhat" org is no longer available for general use.
We have some notes/guidelines that we can update and then point you to.

Mark Eastman (QE):  Pavel may have more details than I but we use these systems to test software before it is released so I am not sure if we can push the images to quay.io during the test phases.
We will look to see if there are other registries at Red Hat that are not in Production, that folks could use.

Regards,
Jeff

Hi Teams,
We are having challenges maintaining the centralized registry with our current capacity.  This central registry at docker-registry.upshift.redhat.com is not a production service, and has low/no SLA.  Going forward, we recommend using quay.io for critical workflows.  If using quay.io is not possible, can you tell us why it is not possible for your team?  In addition, if using quay.io is not possible, what would you suggest as requirements for an 'internal' central registry?

Thanks,
Jeff