Open Stack

On Mon, 2019-01-28 at 10:43 -0500, Mohammed Naser wrote:
> On Mon, Jan 28, 2019 at 10:41 AM Jay Pipes <jaypipes at gmail.com> wrote:
> > 
> > On 01/28/2019 10:24 AM, Mohammed Naser wrote:
> > > Perhaps, we should come up with the first initial step of providing
> > > a common way of building images (so a use can clone a repo and do
> > > 'docker build .') which will eliminate the obligation of having to
> > > deal with binaries, and then afterwards reconsider the ideal way of
> > > shipping those out.
> > 
> > Isn't that precisely what LOCI offers, Mohammed?
> > 
> > Best,
> > -jay
> > 
the problem with that appraoch is we have is we have to bless a specific base image
which effectivly mean that it is
unlikely that this would form the basis of a vendor product.

if that is not the goal. e.g. support a common set of images that can be used in vendor distrobutions
and the target is instead developers, testing and role your own deployemnts that dont use
a downstream vendor distobution that is fine.

if we did want to support vendor distobutiosn we would likely have to do one of the following.
dynamicaly generate the docker file form a template like kolla does so we can set the base image.
that could be as simple as "tox -e continer-build -- base_image=ubuntu:latest"

> I haven't studied LOCI as much however I think that it would be good to
> perhaps look into bringing that approach in-repo rather than out-of-repo
> so a user can simply git clone, docker build .
well im not sure if you have noticed but alot of people cant even agree on "docker build"
lately. personcally i like the idea of tiny base image with python-3, pip and a compiler.
and have a work worflow similar to "tox -e continer-build" which would create the root
files system image by then just pip installing the current project.

if that just does docker build fine by me. i personally dont like the push to abandon all
thinks docker inc and create new tools for exactly the same thing.

the one think  i would urge however regradless of what we decided to do or not do is,
lets not package our depencies
under openstack/.
e.g. we should not aim to have openstack/mysql or openstack/rabbitmq but i would also 
argue we should
not aim to have a nova-libvirt contianer or neutron ovs contianer either.

if the goal was to have in repo definitons of the services own blessed contianer there
is no repo that these dependencies would naturaly fit with and im sure the mysql comunity
can proably do a better job of contaierising it then us.

> I have to admit, I'm not super familiar with LOCI but as far as I know, that's
> indeed what I believe it does.

loci basically does this but unlike kolla it does not define a common abi for how the contiers
are to be run. that has pros and cons but it does mean that every deployment
tool that consumes the loci image basically has to invent it itself which is kind of wastful.

when containerising openstack, neutron and horizon are often the elephants in the room as managing the
installation of vendor/service specific plugins or neutron extension is a pain. 
e.g how do you build an image with networking-ovn and vpnaas and use the same mechanium to build ml2/ovs with
networking-sfc. you either end up installing them all or choosing a subset and people end up building there own
image.

kolla adresses this by generating the dockerfiles dynamically form a template so that you can build with only the
plugins you want and using that same templating you cna select source (git or tarball) or binary installs
and the base distro and architecture. the last point is something that is often forgotten. we do most of our ci on x86
but i hear openstack works really well on arm and power too so what ever images are produced should supprot
those too. loci does not to my knoladge whve mulit distor or multi arch support but based on what little i know
i dont think that is a fundemetal limitation of how it works.