On Mon, Jan 28, 2019 at 10:41 AM Jay Pipes <jaypipes@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
On Mon, 2019-01-28 at 10:43 -0500, Mohammed Naser wrote: 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.