[tripleo] docker.io rate limiting
John Fulton
johfulto at redhat.com
Fri Sep 4 16:42:10 UTC 2020
On Fri, Sep 4, 2020 at 12:13 PM Wesley Hayutin <whayutin at redhat.com> wrote:
>
> On Fri, Sep 4, 2020 at 7:23 AM Giulio Fidente <gfidente at 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/82c71c55/attachment-0001.html>
More information about the openstack-discuss
mailing list