Open Stack

I want to clear up a few things about Loci images. To start with, I would
not be comfortable publishing Loci images to the OpenStack namespace in
Docker Hub because currently they have no functional testing. In several
instances over the past couple of months we've sent up patches to fix
images that just didn't work because of dependency issues. We're working
on a way to do functional testing, and once we're gating with functional
testing on master and stable branches we can revisit the issue.

Still, we assume that deployment tooling will want to modify images
anyway, and specifically designed the build system to accomodate
injecting different binary and python dependencies. Also, Loci does not
provide it's own Makefile for building images. The Dockerfile and
installation scripts use environment variables to control the entire
build process, which makes is very easy to use tools like Make or
Ansible to build the images.

Supporting multiple base operating systems is trivial with Loci and
Docker image tagging. If we do push images to some central location, as a
community we should think about adopting a common tagging strategy for
consitency across all projects. For example, in my own little deployments
I use a naming scheme that follows this pattern:

loci-<project>:<release>-<base>

So Nova from master on Leap15 would be tagged as:

loci-nova:master-leap15

We should be listening to demand for such images, but for now I encourage
people interested in Loci to build their own to suit their particular
needs.

-Chris


> On Jan 30, 2019, at 6:35 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> 
> On 2019-01-30 13:57:03 +0000 (+0000), Sean Mooney wrote:
> [...]
>> i would recommend basing such a container on the offical
>> python:3-alpine image as it is only 30mb and has everything we
>> should need to just pip install the project. it has python 3.7.2
>> currently but the 3-alpine tag tracks both the latest release of
>> alpine and the latest release of python alpine supports.
> 
> In a twist of irony, Python manylinux1 wheels assume glibc and so
> any with C extensions are unusable with Alpine's musl. As a result,
> we'll likely need to cross-compile any of our non-pure-Python
> dependencies from sdist/source with an appropriate toolchain and
> inject them into image.
> 
>> in some rare cases we might need to also install bindeps but i
>> would hope that between bindeps and pip we could build small
>> images for source fairly simpely and leave the orchestration of
>> those images to the enduser.
> [...]
> 
> The bindep tool does at least have support for Alpine now, so as
> long as there are packages available for our system dependencies
> that should hopefully be a viable option.
> -- 
> Jeremy Stanley