<div dir="ltr"><div>Sean,</div><div><br></div><div>The size isn't the primary concern here, just a "small" bonus eventually. Kolla doesn't support ubi8; yes we could have done it but again this is going to be a bunch of work (like it was for RHEL8/centos8) that I'm not sure is worth it if the only consumers are TripleO folks at this point.</div><div><br></div><div>What Alex described is our major motivation to go down that path.</div><div>To be fully transparent with people outside of Red Hat; there are currently 3 extra-layers on top of vanilla kolla images so we can use them downstream. I'm part of the folks who actually maintain them upstream and downstream and I'm tired of solving the problem multiple times at different levels.</div><div>Our proposal is going to make it extremely simple: one YAML file per image with no downstream version of it. No extra overrides; no complications. One file, consumed upstream, downstream everywhere.</div><div><br></div><div>As for customers/partners/third party; it'll be very easy to create their own images. The new interface is basically the Dockerfile one; and we'll make sure this is well documented with proper examples (e.g neutron drivers, etc).</div><div><br></div><div>We have a strong desire to collaborate with the community; for example there is potential work to do on the container images gating with Zuul and such.</div><div>However, based on our usage of Kolla, I believe that it is time to go.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 1, 2020 at 7:27 PM Kevin Carter <<a href="mailto:kecarter@redhat.com">kecarter@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"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br clear="all"></div><div><div dir="ltr"><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" target="_blank">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>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div>