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@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