Open Stack

On Tue, 5 May 2020 at 16:24, Alex Schultz <aschultz at redhat.com> wrote:
>
> On Tue, May 5, 2020 at 9:12 AM Marcin Juszkiewicz
> <marcin.juszkiewicz at linaro.org> wrote:
> >
> > W dniu 05.05.2020 o 15:56, Bogdan Dobrelya pisze:
> > > Let's for a minute imagine that each of the raised concerns is
> > > addressable. And as a thought experiment, let's put here WHAT has to
> > > be addressed for Kolla w/o the need of abandoning it for a custom
> > > tooling:
> >
> > >> 1) input image (centos/ubi0/ubuntu/clear/whatever)
> > >
> > > * support ubi8 base images
> >
> > "kolla-build --base-image ubi8" has you covered. Or you can provide a
> > patch which will switch to ubi8 for some of existing targets. Easy,
> > really.
> >
>
> Yea my list wasn't saying kolla had deficiencies for anything, but
> rather the core concepts that are needed for something like this.
> Infact kolla does tick the boxes for all of these however may be
> opinionated in some areas (e.g. building has to use docker) which may
> not make sense for others to consume. It might also not be in the best
> interest of the project to actually push support for alternative
> solutions if there isn't a larger demand from the community.

Support for buildah (and podman in kolla-ansible) comes up as a
request at most design sessions. It wouldn't be too hard to add, and
wouldn't see resistance from me at least.

>
> > >> 2) Packaging method for the application (source/rpm/dpkg/magic)
> > >
> > > * abstract away all the packaging methods (at least above the base
> > > image) to some (better?) DSL perhaps
> >
> > What is DSL? Digital Subscriber Line? Did Something Likeable? Droids
> > Supporting Legacy?
> >
>
> domain-specific language. The proposal kinda includes something to
> that effect that lets us define a yaml with a specific structure which
> gets turned into a dockerfile equivalent.
>
> > I decided to not follow rest of discussion. Let you guys invent
> > something interesting and working. I can just follow then.
> >
>
> Yea I feel like we're going in circles now. Feel free to follow the
> spec and if it makes sense to contribute it elsewhere or move it we
> can discuss that later.  Right now we're working on something that we
> think addresses our specific needs without having to re-write
> significant portions of other projects and impacting everyone. It may
> not make sense for everyone, but we're investigating it for V.

Clearly a large rewrite of kolla would be likely to get some pushback,
but I expect there are a number of places where Tripleo has worked
around kolla rather than with it. The idea that Tripleo requirements
should not impact kolla is wrong - it is one of two main consumers
(the other being kolla-ansible), and I would like to think we would
accommodate your requirements where possible, if resources are
provided to implement the changes.

>
> Thanks,
> -Alex
>
>