Open Stack

On Mon, Apr 20, 2020 at 2:29 PM Sean Mooney <smooney at redhat.com> wrote:
> On Sat, 2020-04-18 at 16:09 +0200, Radosław Piliszek wrote:
> > My idea is to reuse Kolla engine where it shines: sources collection,
> > system of plugins, hierarchical building; but replace the part that
> > smells - Jinja2 templating.
> i acutlly tought that the use of jinja2 was one of the nicer parts of
> how we build images. its been a long time since i was activly looking at kolla
> but the fact that jinja2 was used both in the image building and in the config
> generation in kolla-ansible was nice as i did not have to learn a new syntax or
> mechanisium for each and could transfer knoladge between them.

It's nice as long as you don't do anything fancy and don't want to run
analysis on them.
The more we rely on jinja2, the more we rely on humans to verify everything.
Unit testing is non-existent.
Under the new model, whatever was easy with jinja2 wouldn't be harder,
and what was convoluted, would no longer be (that much).
(Self-)documenting reliatonships between packages is a nice way to
ensure we bring similar experience regardless of final platform.
With current conditionals hell it's unimaginable to handle other than
by further functional and integration testing (kolla-ansible).

> > Giving up on Jinja2 might encompass giving up on Dockerfile syntax,
> > but that is optional and depends on what makes it more amenable to
> > avoid further pitfalls.
> >
> > With giving up on Jinja2, the idea is to generate building recipes
> > fully programmatically from Python.
> this woudl break our templeate override feature which is how ooo customises
> the images for rhel.

Compatibility layer would be in place.
Kolla already coordinates changes with TripleO and we would keep that in check.

> > It would be possible to introduce "Features" - sets of packages to
> > install based on the (distro, arch) tuple.
> > This would result in more flexibility - turning them on/off (some
> > could be optional, some not).
> > There could be more than one optimization strategy regarding when
> > packages get installed: you want only standalone blah-blah? Then Kolla
> > won't be installing XYZ and ABC just because ugma-ugma and
> > tickle-tickle require them and you "could save some space" (TM).
> > In the same vein, features could declare which components are
> > build-time and which are run-time and this would make it
> > straightforward to separate the sides.
> > The above effort could well be coordinated with different projects to
> > reuse bindep contents. So far Kolla does not use bindep because it
> > often installs too much and not enough at the same time.
> > Do note it would still be bindep-less for external services.
> there was a effort in the past to drop using docker for the building of the images
> to achive a similar goal. specifically the creation of a DSL or a alternitve builder
> that does nto use layers https://review.opendev.org/#/c/503882/
> using either approch woudl allow us to keep jinja/tempelate overrides while
> perhspas still reducing the size of iamges and adressin the build time vs runtime deps
> issue.

Thanks for the link, might come in handy, starred and added to my queue.

-yoctozepto