Open Stack

On Sun, 2020-05-03 at 21:42 +0000, Jeremy Stanley wrote:
> On 2020-05-03 15:32:50 -0600 (-0600), Alex Schultz wrote:
> [...]
> > 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.
> 
> [...]
> 
> My understanding of Mohammed's proposal is that he wants to create
> basic building blocks out of Docker container images which can be
> reused in a variety of contexts

those images will not be usable by a downstream product due to the enforced choice
of disto and install method and the fact that it include packages that are not
supported or exculde packages that are.

so they wont be reusable as a building block for ooo (since the proposed iamges are deb based_ or RHOSP(
since they are not build with the Redhat rpms on rhel with our downstream backports). the docker files also wont
be reusable unless then are configurable at which point you are back to kolla again or each vendor will need to use
there own solution.

as a side note i am not sold on Mohammed's proposal being the right path forward vs just creating another project for
that goal. for example if the intent of using the python slim image as a base is to have a small base iamge that
facilates deps being installed via pip i would suggest that we should be looking at python:alpine instead not the debian
buster slim image. 

> . Opinionated on the underlying
> operating system and installation method, it seems like the
> suggestion is to have something akin to Python sdist or wheel
> packages, but consumable from DockerHub using container-oriented
> tooling instead of from PyPI using pip.
>  The images would in theory
> be built in a templated and consistent fashion taking cues from the
> Python packaging metadata, similar to Monty's earlier PBRX
> experiment maybe.
well that is kind of what kolla was trying to do in a way.
provide a set of templates to build images in a consistent fashion.
i think we could get even more uniformatiy in the kolla images by relying more on bindeps
and have in a set of bindep labels per image to control what gets installed.