<div dir="ltr">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 <a href="http://docker.io/tripleou/*:current-tripelo">docker.io/tripleou/*:current-tripelo</a> ), but how to get a full list?<div><br></div><div>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?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 3 Sep 2020 at 08:57, Cédric Jeanneret <<a href="mailto:cjeanner@redhat.com">cjeanner@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 9/2/20 9:33 PM, Wesley Hayutin wrote:<br>
> <br>
> <br>
> On Wed, Sep 2, 2020 at 8:18 AM Ruslanas Gžibovskis <<a href="mailto:ruslanas@lpic.lt" target="_blank">ruslanas@lpic.lt</a><br>
> <mailto:<a href="mailto:ruslanas@lpic.lt" target="_blank">ruslanas@lpic.lt</a>>> wrote:<br>
> <br>
> Sorry for the stupid question, but maybe there is some parameter for<br>
> tripleo deployment not to generate and download images from docker<br>
> io each time? since I already have it downloaded and working?<br>
> <br>
> Or, as I understand, I should be able to create my own snapshot of<br>
> images and specify it as a source?<br>
> <br>
> <br>
> Yes, as a user you can download the images and push into your own local<br>
> registry and then specify your custom registry in the<br>
> container-prepare-parameters.yaml file. <br>
<br>
that's basically what I'm doing at home, in order to avoid the network<br>
overhead when deploying N times.<br>
<br>
Now, there's a new thing with github that could also be leveraged at<br>
some point:<br>
<a href="https://github.blog/2020-09-01-introducing-github-container-registry/" rel="noreferrer" target="_blank">https://github.blog/2020-09-01-introducing-github-container-registry/</a><br>
<br>
Though the solution proposed by Wes and his Team will be more efficient<br>
imho - fresh build of containers within CI makes perfectly sense. And<br>
using TCIB[1] for that task also provides a new layer of CI for this<br>
central tool, which is just about perfect!<br>
<br>
Cheers,<br>
<br>
C.<br>
<br>
[1]<br>
<a href="https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/3rd_party.html#building-new-containers-with-tripleo-container-image-build" rel="noreferrer" target="_blank">https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/3rd_party.html#building-new-containers-with-tripleo-container-image-build</a><br>
<br>
> <br>
> <br>
> <br>
> <br>
> On Wed, 2 Sep 2020 at 13:58, Wesley Hayutin <<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a><br>
> <mailto:<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>>> wrote:<br>
> <br>
> Greetings,<br>
> <br>
> Some of you have contacted me regarding the recent news<br>
> regarding <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a> <<a href="http://docker.io" rel="noreferrer" target="_blank">http://docker.io</a>>'s new policy with regards<br>
> to container pull rate limiting [1]. I wanted to take the<br>
> opportunity to further socialize our plan that will completely<br>
> remove <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a> <<a href="http://docker.io" rel="noreferrer" target="_blank">http://docker.io</a>> from our upstream workflows<br>
> and avoid any rate limiting issues.<br>
> <br>
> We will continue to upload containers to <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a><br>
> <<a href="http://docker.io" rel="noreferrer" target="_blank">http://docker.io</a>> for some time so that individuals and the<br>
> community can access the containers. We will also start<br>
> exploring other registries like quay and newly announced github<br>
> container registry. These other public registries will NOT be<br>
> used in our upstream jobs and will only serve the communities<br>
> individual contributors.<br>
> <br>
> Our test jobs have been successful and patches are starting to<br>
> merge to convert our upstream jobs and remove <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a><br>
> <<a href="http://docker.io" rel="noreferrer" target="_blank">http://docker.io</a>> from our upstream workflow. [2].<br>
> <br>
> Standalone and multinode jobs are working quite well. We are<br>
> doing some design work around branchful, update/upgrade jobs at<br>
> this time.<br>
> <br>
> Thanks 0/<br>
> <br>
> <br>
> [1] <a href="https://hackmd.io/ermQSlQ-Q-mDtZkNN2oihQ" rel="noreferrer" target="_blank">https://hackmd.io/ermQSlQ-Q-mDtZkNN2oihQ</a><br>
> [2] <a href="https://review.opendev.org/#/q/topic:new-ci-job+(status:open+OR+status:merged)" rel="noreferrer" target="_blank">https://review.opendev.org/#/q/topic:new-ci-job+(status:open+OR+status:merged)</a><br>
> <br>
> <br>
> <br>
> -- <br>
> Ruslanas Gžibovskis<br>
> +370 6030 7030<br>
> <br>
<br>
-- <br>
Cédric Jeanneret (He/Him/His)<br>
Sr. Software Engineer - OpenStack Platform<br>
Deployment Framework TC<br>
Red Hat EMEA<br>
<a href="https://www.redhat.com/" rel="noreferrer" target="_blank">https://www.redhat.com/</a><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Ruslanas Gžibovskis<br>+370 6030 7030<br></div></div></div>