search

boutproject / BOUT-dev

BOUT++: Plasma fluid finite-difference simulation code in curvilinear coordinate systems
http://boutproject.github.io/
GNU Lesser General Public License v3.0
183 stars 95 forks source link

dockerhub images out of date #2186

Open johnomotani opened 3 years ago

johnomotani commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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