<div dir="ltr"><div><div>Hi Mark,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 4, 2020 at 5:02 AM Mark Goddard <<a href="mailto:mark@stackhpc.com">mark@stackhpc.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">Thanks for sharing this Kevin & Emilien. I have mixed feelings about<br>
it. Of course it is sad to see a large consumer of the Kolla images<br>
move on and build something new, rather than improving common tooling.<br></blockquote><div><br></div><div>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.</div><div>If we decide to "leave Kolla"; you can count on us if help is needed for anything.</div><div><br></div><div>For the "build something new rather than improving common tooling"; Alex answered that much better than I can do:</div><div><br></div><div>"(...) 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. (...)"</div><div> </div><div>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.</div><div><br></div><div>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:</div><div>- TripleO overrides in tripleo-common upstream</div><div>- overrides in tripleo-common downstream</div><div>- multiple hacks in tooling to build containers for OSP</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div>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).<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
OTOH, I can see the reasons for doing it, and it has been clear since<br>
Martin Andre left the core team that there was not too much interest<br>
from Red Hat in pushing the Kolla project forward.<br></blockquote><div><br></div><div>To be fair, no. The review velocity in Kolla is not bad at all and you folks are always nice to work with. Really.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I will resist the urge to bikeshed on image size :)<br></blockquote><div><br></div><div>So talking about image size in the thread was my idea and I shouldn't have done that.</div><div>I'll say it again here: the image size wasn't our main driver for that change. It has always been a bonus only.</div><div>I rebuilt images with our new tooling last night; based on centos8 and I got the same sizes as the Kolla images.</div><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I will make an alternative proposal, although I expect it has at least<br>
one fatal flaw. Kolla is composed mainly of two parts - a kolla-build<br>
Python tool (the aforementioned *glorious* templating engine) and a<br>
set of Dockerfile templates. It's quite possible to host your own<br>
collection of Dockerfile templates, and pass these to kolla-build via<br>
--docker-dir. Tripleo could maintain its own set, and cut out the<br>
uninteresting parts over time. The possibly fatal flaw? It wouldn't<br>
support the buildah shell format. It is just another template format<br>
though, perhaps it could be made to work with minimal changes. The<br>
benefit would be that you get to keep the template override format<br>
that is (presumably) exposed to users.<br></blockquote><div> </div><div>This should _at very least_ be a documented alternative in the spec proposed by Kevin.</div><div>I agree we should take a look and I just discussed with Kevin and we'll do it this week and report back.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If you do decide to go (I expect that decision has already been made),<br>
please keep us in the loop.</blockquote><div><br></div><div>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.</div><div>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.<br></div><div><br></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">We will of course continue to support Tripleo for as long as necessary, but if you could provide us with a<br>
timeframe it will help us to plan life after Tripleo. We're also<br>
looking for ways to streamline and simplify, and as Alex mentioned,<br>
this opens up some new possibilities. At the very least we can drop<br>
the tripleoclient image :)<br></blockquote><div><br></div><div>re: tripleoclient image: let's remove it now. It was never useful. I'll propose a patch this week.</div><div>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).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Finally, if you could share any analysis that ends up being done on<br>
the images, and outcomes from it (e.g. drop these packages), that<br>
would be a nice parting gift.<br>
</blockquote></div><br clear="all"></div><div>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.</div><div><br></div><div>Thanks,<br></div><div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div></div></div>