dockerhub images out of date

[johnomotani]

The images on https://hub.docker.com/u/boutproject/ are out of date. This may cause problems (https://github.com/boutproject/xBOUT/issues/178). Do we intend to provide these images? If so it would be nice to have one for the latest release at least, maybe update them as part of the release process? If not, maybe we should take down the out of date ones, and remove the instructions in the manual at https://bout-dev.readthedocs.io/en/latest/user_docs/installing.html?highlight=docker#docker-image to avoid confusion?

[ZedThree]

It looks like it's possible to get them to auto-build, but we'd need to have the Dockerfile in this repo -- currently, there's a separate repo (https://github.com/boutproject/docker-bout) with all the build scripts in.

[bendudson]

I'm trying to get them working for the latest release. Unfortunately Centos7 has an ancient compiler (gcc 4.8.5) which won't compile BOUT++ master. I've loaded devtoolset-7 to get gcc 7, but then linking fails when --enable-shared is used.

[bendudson]

I've built some up-to-date images, now on dockerhub: https://hub.docker.com/u/boutproject

• boutproject/bout-master:3b23201-arch Latest master with Sundials (2.7.0) and PETSc (3.14.2)
• boutproject/bout-master:3b23201-sundials-arch Latest master with just Sundials (2.7.0)
• boutproject/bout-next:4cee87c-arch Latest next with Sundials (2.7.0) and PETSc (3.14.2)
• boutproject/bout-next:4cee87c-sundials-arch Latest next with just Sundials (2.7.0)

All based on Arch linux. I don't mind which distribution we use, but Centos seems to be a dead end, and at least Arch is up to date.

@ZedThree Is it possible to have releases auto-built if the docker scripts are in a submodule? Having releases automatically built and pushed to Docker Hub would be handy.

[johnomotani]

In principle I guess we don't even need the scripts in a submodule? A Github action to run on release could clone https://github.com/boutproject/docker-bout and run something in there. We use release actions for uploading the Python projects to PyPi, e.g. https://github.com/boutproject/xBOUT/blob/master/.github/workflows/pythonpublish.yml.

[ZedThree]

Thanks @bendudson!

It looks like having the dockerfile in a submodule might be tricky, so a Github action might be the better way to go.

[johnomotani]

At the moment in the docs (https://bout-dev.readthedocs.io/en/latest/user_docs/installing.html) the 'Docker image' option is the first one listed and "the quickest way to get started", so it looks like this is what we recommend - do we want to recommend it? Should we maybe move it further down the page, modify the intro*? In any case the docs are out of date:

$ sudo docker pull boutproject/boutproject/bout-next:9f4c663-petsc

refers to a 3 year old version of BOUT++, which can cause problems (https://github.com/boutproject/xBOUT/issues/211). I don't know Docker, but is the long term solution (once this issue is fixed) to be able to do something like

$ sudo docker pull boutproject/release

to always get the latest released version?

* Possible modified intro, if we don't want to recommend Docker image:

This section goes through the process of getting, installing, and
starting to run BOUT++. 

It is recommended in most cases to manually install BOUT++ by following
the steps below. Only the basic functionality needed to use BOUT++ is
described here; the next section (:ref:`sec-advancedinstall`) goes through
more advanced options, configurations for particular machines, and how
to fix some common problems.

It is also possible to use a pre-built binary. These take care of all
dependencies, configuration and compilation, but (at present) are only
updated irregularly. See section :ref:`sec-prebuiltinstall`.

[dschwoerer]

with charliecloud recomending images might actually be a solution that is also suitable for HPC runs.

Including instructions to build on release shouldn't be that hard, it would probably be added to our release script

However, the main issue I see with binary releases, is that we need at least 2 version, one optimized for production runs and one for debug runs. In addition different builds for openmpi and mpich are probably needed.

I think that would be quite promising, but might need some further work, to be able to recommend that to users ...