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/deployment/3rd_party.html#building-new-containers-with-tripleo-container-image-build

>
>  
>
>
>     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/
>
>
>         [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/



--
Ruslanas Gžibovskis
+370 6030 7030