Open Stack

On Fri, 1 May 2020 at 21:19, Kevin Carter <kecarter at redhat.com> wrote:
>
> Hello Stackers,
>
> As you may have seen, the TripleO project has been testing the idea of building container images using a simplified toolchain [0]. The idea is to build smaller, more easily maintained images to simplify the lives of TripleO consumers. Since TripleO's move to containers, the project has been leveraging Kolla to provide Dockerfiles, and while this has worked, TripleO has created considerable tooling to bend Kolla images to its needs. Sadly this has resulted in an image size explosion and the proliferation of difficult to maintain tools, with low bus factors, which are essential to the success of the project. To address the risk centered around the TripleO containerization story, we've drafted a spec [0], which we believe outlines a more sustainable future. In this specification, we've designed a new, much more straightforward, approach to building container images for the TripleO project. The "simple container generation," specification does not intend to be a general-purpose tool used to create images for the greater OpenStack community, both Loci and Kolla do that already. This effort is to build containers only for TripleO using distro provided repositories, with distro maintained tooling. By focusing only on what we need, we're able to remove all general-purpose assumptions and create a vertically integrated stack resulting in a much smaller surface area.
>
> To highlight how all this works, we've put together several POC changes:
> * Role and playbook to implement the Containerfile specification [1].
> * Tripleoclient review to interface with the new role and playbook [2].
> * Directory structure for variable file layout [3].
> * To see how this works using the POC code, building images we've tested in real deployments, please watch the ASCII-cast [4].
> * Example configuration file examples are here [5][6][7].
>
> A few examples of size comparisons between our proposed tooling versus current Kolla based images [8]:
>   - base:
>       + Kolla: 588 MB
>       - new: 211 MB  # based on ubi8, smaller than centos8
>   - nova-base:
>       + Kolla: 1.09 GB
>       - new: 720 MB
>   - nova-libvirt:
>       + Kolla: 2.14 GB
>       - new: 1.9 GB
>   - keystone:
>       + Kolla: 973 MB
>       - new: 532 MB
>   - memcached:
>       + Kolla: 633 MB
>       - new: 379 MB
>
> While the links shown are many, the actual volume of the proposed change is small, although the impact is massive:
> * With more straightforward to understand tools, we'll be able to get broader participation from the TripleO community to maintain our containerization efforts and extend our service capabilities.
> * With smaller images, the TripleO community will serve OpenStack deployers and operators better; less bandwidth consumption and faster install times.
>
> We're looking to chart a more reliable path forward, and making the TripleO user experience a great one. While the POC changes are feature-complete and functional, more work is needed to create the required variable files; however, should the proposed specification be ratified, we expect to make quick work of what's left. As such, if you would like to be involved or have any feedback on anything presented here, please don't hesitate to reach out.
>
> We aim to provide regular updates regarding our progress on the "Simple container generation" initiative, so stay tuned.

Thanks for sharing this Kevin & Emilien. I have mixed feelings about
it. Of course it is sad to see a large consumer of the Kolla images
move on and build something new, rather than improving common tooling.
OTOH, I can see the reasons for doing it, and it has been clear since
Martin Andre left the core team that there was not too much interest
from Red Hat in pushing the Kolla project forward.

I will resist the urge to bikeshed on image size :)

I will make an alternative proposal, although I expect it has at least
one fatal flaw. Kolla is composed mainly of two parts - a kolla-build
Python tool (the aforementioned *glorious* templating engine) and a
set of Dockerfile templates. It's quite possible to host your own
collection of Dockerfile templates, and pass these to kolla-build via
--docker-dir. Tripleo could maintain its own set, and cut out the
uninteresting parts over time. The possibly fatal flaw? It wouldn't
support the buildah shell format. It is just another template format
though, perhaps it could be made to work with minimal changes. The
benefit would be that you get to keep the template override format
that is (presumably) exposed to users.

If you do decide to go (I expect that decision has already been made),
please keep us in the loop. We will of course continue to support
Tripleo for as long as necessary, but if you could provide us with a
timeframe it will help us to plan life after Tripleo. We're also
looking for ways to streamline and simplify, and as Alex mentioned,
this opens up some new possibilities. At the very least we can drop
the tripleoclient image :)

Finally, if you could share any analysis that ends up being done on
the images, and outcomes from it (e.g. drop these packages), that
would be a nice parting gift.

>
> Thanks,
>
> Kevin and Emilien
>
> [0] https://review.opendev.org/#/c/723665/
> [1] https://review.opendev.org/#/c/722557/
> [2] https://review.opendev.org/#/c/724147/
> [3] https://review.opendev.org/#/c/722486/
> [4] https://files.macchi.pro:8443/demo-container-images/
> [5] http://paste.openstack.org/show/792995/
> [6] http://paste.openstack.org/show/792994/
> [7] http://paste.openstack.org/show/792993/
> [8] https://4ce3fa2efa42bb6b3a69-771991cd07d409aaec3e4ca5eafdd7e0.ssl.cf2.rackcdn.com/724436/2/check/tripleo-build-containers-centos-8/78eefc3/logs/containers-successfully-built.log
>
> Kevin Carter
> IRC: kecarter