<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">Kevin Carter</font></div><div><font face="courier new, monospace">IRC: kecarter</font></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 1, 2020 at 5:57 PM Alex Schultz <<a href="mailto:aschultz@redhat.com">aschultz@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">On Fri, May 1, 2020 at 4:12 PM Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>> wrote:<br>
><br>
> On Fri, 2020-05-01 at 15:18 -0500, Kevin Carter wrote:<br>
> > Hello Stackers,<br>
> ><br>
> > As you may have seen, the TripleO project has been testing the idea of<br>
> > building container images using a simplified toolchain [0]. The idea is to<br>
> > build smaller, more easily maintained images to simplify the lives of<br>
> > TripleO consumers. Since TripleO's move to containers, the project has been<br>
> > leveraging Kolla to provide Dockerfiles, and while this has worked, TripleO<br>
> > has created considerable tooling to bend Kolla images to its needs. Sadly<br>
> > this has resulted in an image size explosion and the proliferation of<br>
> > difficult to maintain tools, with low bus factors, which are essential to<br>
> > the success of the project. To address the risk centered around the TripleO<br>
> > containerization story, we've drafted a spec [0], which we believe outlines<br>
> > a more sustainable future. In this specification, we've designed a new,<br>
> > much more straightforward, approach to building container images for the<br>
> > TripleO project. The "simple container generation," specification does not<br>
> > intend to be a general-purpose tool used to create images for the greater<br>
> > OpenStack community, both Loci and Kolla do that already. This effort is to<br>
> > build containers only for TripleO using distro provided repositories, with<br>
> > distro maintained tooling. By focusing only on what we need, we're able to<br>
> > remove all general-purpose assumptions and create a vertically integrated<br>
> > stack resulting in a much smaller surface area.<br>
> ><br>
> > To highlight how all this works, we've put together several POC changes:<br>
> > * Role and playbook to implement the Containerfile specification [1].<br>
> > * Tripleoclient review to interface with the new role and playbook [2].<br>
> > * Directory structure for variable file layout [3].<br>
> > * To see how this works using the POC code, building images we've tested in<br>
> > real deployments, please watch the ASCII-cast [4].<br>
> > * Example configuration file examples are here [5][6][7].<br>
> ><br>
> > A few examples of size comparisons between our proposed tooling versus<br>
> > current Kolla based images [8]:<br>
> >   - base:<br>
> >       + Kolla: 588 MB<br>
> >       - new: 211 MB  # based on ubi8, smaller than centos8<br>
> kolla could also use the ubi8 image as a base you could select centos as the base image type and then pass the url to<br>
> the ubi image and that should would work.<br>
<br>
<br>
ubi8 is smaller, but it doesn't account for it all. We're likely not<br>
importing some other deps that make it into the normal base that<br>
perhaps we don't need. I'd still like to see rpm diffs to better<br>
understand if this savings is real.<br></blockquote><div><br><div class="gmail_default" style="font-family:"courier new",monospace">+1 I think it would be a good exercise to produce an RPM diff for a set of images. Maybe just the ones we've already ported?</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> >   - nova-base:<br>
> >       + Kolla: 1.09 GB<br>
> >       - new: 720 MB<br>
> unless you are using layers fo rthe new iamge keep in mind you have to subtract the size of the base imag form the nova<br>
> base image to caluate how big it actully is so its acully only usein about 500MB<br>
><br>
> if you are using layser for the ubi nova-base then these iamge are actully the same size the diffenrec is entirly coming<br>
> for the reduction in the base image<br>
> >   - nova-libvirt:<br>
> >       + Kolla: 2.14 GB<br>
> >       - new: 1.9 GB<br>
> again here you have to do the same arithmatich  so 2.14-1.09 so this image is adding 1.05 GB of layers in the kolla case<br>
> and the ubi version is adding 1.2GB so the ubi image is acully using more space assumign tis using layer if tis not then<br>
> its 1.05GB vs 1.9GB and the kolla image still comes out better by an even larger margin<br>
> >   - keystone:<br>
> >       + Kolla: 973 MB<br>
> >       - new: 532 MB<br>
><br>
> again here this si all in the deleta of the base image<br>
> >   - memcached:<br>
> >       + Kolla: 633 MB<br>
> >       - new: 379 MB<br>
><br>
> as is this<br>
><br>
> so over all i think the ubi based iamges are using more or the same space then the kolla ones.<br>
> they just have a smaller base image. so rather then doing this i think it makes more sense to just use the ubi iamge<br>
> with the kolla build system unless you expect be be able to signicicalty reduce the size of the images more.<br>
><br>
> based on size alone i tone se anny really benifit so far<br>
> ><br>
> > While the links shown are many, the actual volume of the proposed change is<br>
> > small, although the impact is massive:<br>
><br>
> > * With more straightforward to understand tools, we'll be able to get<br>
> > broader participation from the TripleO community to maintain our<br>
> > containerization efforts and extend our service capabilities.<br>
> given customer likely have built up ther own template override files unless you also have a way to support that this is<br>
> a breaking change to there workflow.<br>
> > * With smaller images, the TripleO community will serve OpenStack deployers<br>
> > and operators better; less bandwidth consumption and faster install times.<br>
> again when you take into the account that kolla uses layers the image dont appear to be smaller and the nova-libvert<br>
> image is actully bigger kolla gets large space saving buy using the copy on write layers that make up docker images<br>
> to share common code so you can just look a the size fo indivigual iamages you have look at the size of the total set<br>
> and compare those.<br>
><br>
> ><br>
> > We're looking to chart a more reliable path forward, and making the TripleO<br>
> > user experience a great one. While the POC changes are feature-complete and<br>
> > functional, more work is needed to create the required variable files;<br>
> > however, should the proposed specification be ratified, we expect to make<br>
> > quick work of what's left. As such, if you would like to be involved or<br>
> > have any feedback on anything presented here, please don't hesitate to<br>
> > reach out.<br>
> ><br>
> > We aim to provide regular updates regarding our progress on the "Simple<br>
> > container generation" initiative, so stay tuned.<br>
> honestly im not sure this is a benifty or something that should be done but it seam like ye have already decieded on a<br>
> path. not the kolla image can also be made smaller then they currently are using multi state builds to remove and deps<br>
> installed for buidl requirement or reducing the optional depencies.<br>
><br>
> many for the deps currently installed are to supprot the different vender backedns.<br>
> if we improve the bindep files in each project too group those depencies by the optional backedn kolla could easily be<br>
> updated to use bindep for package installation. and the image would get even smaller.<br>
<br>
The issues that we (tripleo) have primarily run into are the<br>
expectations around versions (rabbitmq being the latest) and being<br>
able to deploy via source.  Honestly if tripleo was going to support<br>
installations running source or alternative distros (which neither we<br>
currently plan to do), it would likely make sense to continue down the<br>
Kolla path. However we already end up doing so many overrides to the<br>
standard Kolla container configurations[0] that I'm not sure it really<br>
makes sense to continue. Additionally since we no longer support<br>
building via docker, we're basically using kolla as a glorified<br>
template engine to give us Dockerfiles.  The proposal is to stop using<br>
Kolla as a glorified templating engine and actually just manage one<br>
that fits our needs.  We're using a very specific path through the<br>
Kolla code and I'm uncertain if it's beneficial for either of us<br>
anymore.  This also frees up kolla + kolla-ansible improve their<br>
integration and likely be able to make some of the tougher choices<br>
that they've brought up in the other email about the future of kolla.<br>
<br>
Personally I see this move as freeing up Kolla to be able to innovate<br>
and TripleO being able to simplify.  As one of the few people who know<br>
how the container sausage is made in the TripleO world, I think it's<br>
likely for the best.<br>
<br>
[0] <a href="https://opendev.org/openstack/tripleo-common/src/branch/master/container-images/tripleo_kolla_template_overrides.j2" rel="noreferrer" target="_blank">https://opendev.org/openstack/tripleo-common/src/branch/master/container-images/tripleo_kolla_template_overrides.j2</a><br>
<br>
> ><br>
> > Thanks,<br>
> ><br>
> > Kevin and Emilien<br>
> ><br>
> > [0] <a href="https://review.opendev.org/#/c/723665/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/723665/</a><br>
> > [1] <a href="https://review.opendev.org/#/c/722557/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/722557/</a><br>
> > [2] <a href="https://review.opendev.org/#/c/724147/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/724147/</a><br>
> > [3] <a href="https://review.opendev.org/#/c/722486/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/722486/</a><br>
> > [4] <a href="https://files.macchi.pro:8443/demo-container-images/" rel="noreferrer" target="_blank">https://files.macchi.pro:8443/demo-container-images/</a><br>
> > [5] <a href="http://paste.openstack.org/show/792995/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/792995/</a><br>
> > [6] <a href="http://paste.openstack.org/show/792994/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/792994/</a><br>
> > [7] <a href="http://paste.openstack.org/show/792993/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/792993/</a><br>
> > [8]<br>
> ><br>
> <a href="https://4ce3fa2efa42bb6b3a69-771991cd07d409aaec3e4ca5eafdd7e0.ssl.cf2.rackcdn.com/724436/2/check/tripleo-build-containers-centos-8/78eefc3/logs/containers-successfully-built.log" rel="noreferrer" target="_blank">https://4ce3fa2efa42bb6b3a69-771991cd07d409aaec3e4ca5eafdd7e0.ssl.cf2.rackcdn.com/724436/2/check/tripleo-build-containers-centos-8/78eefc3/logs/containers-successfully-built.log</a><br>
> ><br>
> > Kevin Carter<br>
> > IRC: kecarter<br>
><br>
><br>
<br>
</blockquote></div></div>