[tripleo] docker.io rate limiting

Cédric Jeanneret cjeanner at redhat.com
Thu Sep 3 05:54:22 UTC 2020



On 9/2/20 9:33 PM, Wesley Hayutin wrote:
> 
> 
> On Wed, Sep 2, 2020 at 8:18 AM Ruslanas Gžibovskis <ruslanas at lpic.lt
> <mailto:ruslanas at lpic.lt>> wrote:
> 
>     Sorry for the stupid question, but maybe there is some parameter for
>     tripleo deployment not to generate and download images from docker
>     io each time? since I already have it downloaded and working?
> 
>     Or, as I understand, I should be able to create my own snapshot of
>     images and specify it as a source?
> 
> 
> Yes, as a user you can download the images and push into your own local
> registry and then specify your custom registry in the
> container-prepare-parameters.yaml file.  

that's basically what I'm doing at home, in order to avoid the network
overhead when deploying N times.

Now, there's a new thing with github that could also be leveraged at
some point:
https://github.blog/2020-09-01-introducing-github-container-registry/

Though the solution proposed by Wes and his Team will be more efficient
imho - fresh build of containers within CI makes perfectly sense. And
using TCIB[1] for that task also provides a new layer of CI for this
central tool, which is just about perfect!

Cheers,

C.

[1]
https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/3rd_party.html#building-new-containers-with-tripleo-container-image-build

> 
>  
> 
> 
>     On Wed, 2 Sep 2020 at 13:58, Wesley Hayutin <whayutin at redhat.com
>     <mailto:whayutin at redhat.com>> 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.
> 
>         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.
> 
>         Our test jobs have been successful and patches are starting to
>         merge to convert our upstream jobs and remove docker.io
>         <http://docker.io> from our upstream workflow.  [2].
> 
>         Standalone and multinode jobs are working quite well.  We are
>         doing some design work around branchful, update/upgrade jobs at
>         this time.
> 
>         Thanks 0/
> 
> 
>         [1] https://hackmd.io/ermQSlQ-Q-mDtZkNN2oihQ
>         [2] https://review.opendev.org/#/q/topic:new-ci-job+(status:open+OR+status:merged)
> 
> 
> 
>     -- 
>     Ruslanas Gžibovskis
>     +370 6030 7030
> 

-- 
Cédric Jeanneret (He/Him/His)
Sr. Software Engineer - OpenStack Platform
Deployment Framework TC
Red Hat EMEA
https://www.redhat.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/c0ef329c/attachment.sig>


More information about the openstack-discuss mailing list