I am a complete noob in containers, and especially in images. is there a small "howto" get all OSP related images and (upload to local storage is podman pull docker.io/tripleou/*:current-tripelo ), but how to get a full list? Cause when I specify undercloud itself :) it do not have ceilometer-compute, but I have ceilometer disabled, so I believe this is why it did not download that image. but in general, as I understood, it checks all and then selects what it needs? On Thu, 3 Sep 2020 at 08:57, Cédric Jeanneret <cjeanner@redhat.com> wrote:
On 9/2/20 9:33 PM, Wesley Hayutin wrote:
On Wed, Sep 2, 2020 at 8:18 AM Ruslanas Gžibovskis <ruslanas@lpic.lt <mailto:ruslanas@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/deployme...
On Wed, 2 Sep 2020 at 13:58, Wesley Hayutin <whayutin@redhat.com <mailto:whayutin@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/
https://review.opendev.org/#/q/topic:new-ci-job+(status:open+OR+status:merge...)
-- 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/
-- Ruslanas Gžibovskis +370 6030 7030