On Fri, Sep 4, 2020 at 12:13 PM Wesley Hayutin <whayutin@redhat.com> wrote:

On Fri, Sep 4, 2020 at 7:23 AM Giulio Fidente <gfidente@redhat.com> wrote:
On 9/2/20 1:54 PM, Wesley Hayutin wrote:
> Greetings,
>
> Some of you have contacted me regarding the recent news regarding
> docker.io <http://docker.io>'s new policy with regards to container pull
> rate limiting [1]. I wanted to take the opportunity to further
> socialize our plan that will completely remove docker.io
> <http://docker.io> from our upstream workflows and avoid any rate
> limiting issues.

thanks; I guess this will be a problem for the ceph containers as well

> We will continue to upload containers to docker.io <http://docker.io>
> for some time so that individuals and the community can access the
> containers. We will also start exploring other registries like quay and
> newly announced github container registry. These other public registries
> will NOT be used in our upstream jobs and will only serve the
> communities individual contributors.

I don't think ceph found alternatives yet, but Guillaume or Dimitri
might know more about it
--

talk to Fulton.. I think we'll have ceph covered from a tripleo perspective. Not sure about anything else.

Yes, thank you Wes for your help on the plan to cover the TripleO CI perspective. A thread similar to this one has been posted on ceph-dev [1] the outcome so far is that some Ceph projects are using quay.ceph.com to store temporary CI images to deal with the docker.io rate limits.

As per an IRC conversation I had with Dimitri, ceph-ansible is not using quay.ceph.com but has made some changes to deal with current rate limits [2]. I expect they'll need to make further changes for November but my understanding is that they're still looking to push the authoritative copy of the Ceph container image [3] we use to docker.io.

On the TripleO side we change that image rarely so provided it can be cached for CI jobs we should be safe. When we do change the image to the newer version we use a DNM patch [4] to pull it directly from docker. We could continue to do this as only that patch would be vulnerable to the rate limit. If we then see by way of the CI to the DNM patch that the new image is good, we can pursue getting it cached as the new image for TripleO CI Ceph jobs. One thing that's not clear to me is the mechanism to do this.

John

[1] https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/BYZOGN3Y3CJLY35QLDL7SX6SOX74YZCE/#BYZOGN3Y3CJLY35QLDL7SX6SOX74YZCE

[2] https://github.com/ceph/ceph-container/blob/master/tests/tox.sh#L86-L110

[3] https://hub.docker.com/r/ceph/daemon

[4] https://review.opendev.org/#/c/690036/

Giulio Fidente
GPG KEY: 08D733BA