Open Stack

On Sat, May 2, 2020 at 7:45 AM Jeremy Stanley <fungi at yuggoth.org> wrote:
>
> On 2020-05-01 15:18:13 -0500 (-0500), Kevin Carter wrote:
> > As you may have seen, the TripleO project has been testing the
> > idea of building container images using a simplified toolchain
> [...]
>
> Is there an opportunity to collaborate around the proposed plan for
> publishing basic docker-image-based packages for OpenStack services?
>
>     https://review.opendev.org/720107
>
> Obviously you're aiming at solving this for a comprehensive
> deployment rather than at a packaging level, just wondering if
> there's a way to avoid having an explosion of different images for
> the same services if they could ultimately use the same building
> blocks. (A cynical part of me worries that distro "party lines" will
> divide folks on what the source of underlying files going into
> container images should be, but I'm sure our community is better
> than that, after all we're all in this together.)
>

I think this assumes we want an all-in-one system to provide
containers. And we don't.  That I think is the missing piece that
folks don't understand about containers and what we actually need.

I believe the issue is that the overall process to go from zero to an
application in the container is something like the following:

1) input image (centos/ubi0/ubuntu/clear/whatever)
2) Packaging method for the application (source/rpm/dpkg/magic)
3) dependencies provided depending on item #1 & 2
(venv/rpm/dpkg/RDO/ubuntu-cloud/custom)
4) layer dependency declaration (base -> nova-base -> nova-api,
nova-compute, etc)
5) How configurations are provided to the application (at run time or at build)
6) How application is invoked when container is ultimately launched
(via docker/podman/k8s/etc)
7) Container build method (docker/buildah/other)

The answer to each one of these is dependent on the expectations of
the user or application consuming these containers.  Additionally this
has to be declared for each dependent application as well
(rabbitmq/mariadb/etc). Kolla has provided this at a complexity cost
because it needs to support any number of combinations for each of
these.  Today TripleO doesn't use the build method provided by Kolla
anymore because we no longer support docker.  This means we only use
Kolla to generate Dockerfiles as inputs to other processes. It should
be noted that we also only want Dockerfiles for the downstream because
they get rebuilt with yet another different process. So for us, we
don't want the container and we want a method for generating the
contents of the container.

IMHO containers are just glorified packaging (yet again and one that
lacks ways of expressing dependencies which is really not beneficial
for OpenStack).  I do not believe you can or should try to unify the
entire container declaration and building into a single application.
You could rally around a few different sets of tooling that could
provide you the pieces for consumption. e.g. A container file
templating engine, a building engine, and a way of
expressing/consuming configuration+execution information.

I applaud the desire to try and unify all the things, but as we've
seen time and time again when it comes to deployment, configuration
and use cases. Trying to solve for all the things ends up having a
negative effect on the UX because of the complexity required to handle
all the cases (look at tripleo for crying out loud).  I believe it's
time to stop trying to solve all the things with a giant hammer and
work on a bunch of smaller nails and let folks construct their own
hammer.

Thanks,
-Alex




> Either way, if they can both make use of the same speculative
> container building workflow pioneered in Zuul/OpenDev, that seems
> like a huge win (and I gather the Kolla "krew" are considering
> redoing their CI jobs along those same lines as well).
> --
> Jeremy Stanley