Open Stack

Hi Mark,

On Mon, May 4, 2020 at 5:02 AM Mark Goddard <mark at stackhpc.com> wrote:

> 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.
>

Please keep in mind that we're not doing this work because we're seeking
for work (we're already pretty busy with some other topics); although the
container images discussion has been on the table for a very long time and
I think it's the right time to finally take some actions.
If we decide to "leave Kolla"; you can count on us if help is needed for
anything.

For the "build something new rather than improving common tooling"; Alex
answered that much better than I can do:

"(...) 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. (...)"

The way Kevin and I worked is simple: we met with the folks who actually
built the containers for TripleO and acknowledged the gap between the
upstream tooling and how it's being consumed downstream. There is a high
amount of complexity in the middle that we aim to solve in our proposed
solution.

For example, one condition of satisfaction of the new tooling is that it
has to be directly consumable without having to override anything and the
code / configs are 100% upstream. With the Kolla tooling, we are far from
it:
- TripleO overrides in tripleo-common upstream
- overrides in tripleo-common downstream
- multiple hacks in tooling to build containers for OSP

Not great uh? Yes, someone could blame Red Hat for not contributing all the
changes back to Kolla but this isn't that easy if you have been involved in
these efforts yourself.

For once, we have a strong desire to make it 100% public with no hacks, and
it should never affect our TripleO consumers (upstream or downstream).
In fact, it'll enable more integration to patch containers from within our
Deployment Framework and solve other problems not covered in that thread
(hotfix, etc).

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.
>

To be fair, no. The review velocity in Kolla is not bad at all and you
folks are always nice to work with. Really.


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

So talking about image size in the thread was my idea and I shouldn't have
done that.
I'll say it again here: the image size wasn't our main driver for that
change. It has always been a bonus only.
I rebuilt images with our new tooling last night; based on centos8 and I
got the same sizes as the Kolla images.

So unless we go with ubi8 (which I know could have been done with Kolla as
well I'm sure); the image size won't be any smaller.

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.
>

This should _at very least_ be a documented alternative in the spec
proposed by Kevin.
I agree we should take a look and I just discussed with Kevin and we'll do
it this week and report back.

If you do decide to go (I expect that decision has already been made),
> please keep us in the loop.


No decision has been made. To be fully transparent, Kevin and I worked on a
prototype during 6 days, proposed a spec the 7th day and here we are.
We'll do this in the open and again in full transparency; we acknowledge
that we have put ourselves in that position but we aim to fix it.



> 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 :)
>

re: tripleoclient image: let's remove it now. It was never useful. I'll
propose a patch this week.
Yes we will keep you in the loop and thanks for your willingness to
maintain Kolla during our transition. Note that this is a two-side thing.
We are also happy to keep working with you, maybe on some other aspects
(maintaining centos8, CI, etc).

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.
>

Yes I have a bunch of things that I'm not sure they are useful anymore.
I'll make sure we document it in etherpad and share it with you asap.

Thanks,
-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200504/d35c2511/attachment.html>