Open Stack

On Sun, May 3, 2020 at 2:35 PM Tobias Urdin <tobias.urdin at binero.com> wrote:
>
> Interesting discussion going on in this thread!
>
> From a mostly operator viewpoint (and CentOS-only shop) we've closely been monitoring what way
> Red Hat's enterprise based products has been taking and been planing for a while to explore the
> Kolla-based containers route due to the backing of Red Hat's usage.
>
> Now based on TripleO's usecase it's understandable to make their tooling easier but I think this
> also starts rooting into the OpenStack official containers and "make OpenStack more application like"
> that Mohammed Naser was digging into with his TC application.
>

The crux of all of this is what is the official base and software
packaging/distribution method.  "Official Images" are nice but likely
can't be consumed by a number of folks due to the previous two items.
Whenever folks are talking containers they should s/container/package/
and ask the same questions.  Providing "Official Images" seems to go
against the original intent of letting folks build what they need as
they need it. Having lived in the deployment of openstack for 5 years
now, I can tell you just having a thing doesn't solve anything when it
comes to OpenStack.  Not really certain what the intent of this effort
is. I guess I should go read up on it.

> Operating an OpenStack deployment today is hard, but much better and enterprise than before,
> upgrading OpenStack now is a dream (jumped Rocky -> Train just some weeks ago) compared to
> before but my opinion is that we are missing a lot of view on OpenStack as an application today.
>
> It would be sad to see Red Hat's involvement in Kolla scale down.
> Just my 2c which probably was mostly offtopic from TripleO, my apologies for that.
>

There hasn't really been much involvement in Kolla in some time.  It
was mostly static unless we found a bug or need to add some new
packages/containers.  Dependencies get pulled in mostly by way of the
rpms that are installed so with the exception of building, there isn't
much to do anymore. We did provide some python3 conversion bits as we
hit them but I felt like it was more of just having to find all the
places where the package names needed to be changed and adding logic.
There isn't anything wrong with the Kolla images themselves and it's
more of being able to rebuild containers and their consumption that
seems to be something that isn't exactly solved by any of the items
being discussed.

I've always been a proponent of building blocks and letting folks put
them together to make something that fits their needs.  The current
discussions around containers doesn't seem to be aligned with this.
We're currently investigating how we can create building blocks that
can be consumed to result in containers. 1) container file generation,
2) building 3) distribution.  The first item is a global problem and
is really the main thing that people will continue to struggle with as
it depends on what you're packaging together.  Be it UBI8+RPMS,
Ubuntu+debian packaging, Ubuntu+cloud dpkgs, Clear LInux+source, etc.
That all gets defined in the container file.  The rest is building
from that and distributing the output.  Kolla today does all three
things and allows for any of the base container + packaging methods.
Since we (tripleo) need these 3 items to remain distinct blocks for
various reasons, we would like to seem them remain independent but
that seems to go against what anyone else wants.

> Best regards
> Tobias
> ________________________________________
> From: Alex Schultz <aschultz at redhat.com>
> Sent: Sunday, May 3, 2020 9:26 PM
> To: Jeremy Stanley
> Cc: OpenStack Discuss
> Subject: Re: [tripleo] Container image tooling roadmap
>
> 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
>
>
>
>