Volume mounting behaviour has changed in the latest version of the Docker image #222
Labels
bug
Something isn't working
Comments
|
After further investigation, I think this is a difference in the behaviour around mounted volumes between the previous and current base Docker images, but it isn't a failure to mount the volumes as I previously suspected. Instead it looks like a difference in how each image allows you to specify paths under the volume mount point. Using the old image, I can mount the volume at If I do the same thing with the new image, I cannot see the directory: However, this is not because the volume has failed to mount. We can see it as a file system inside the container: Rather, we cannot see the directory because we can no longer get away with omitting the leading slash from the path. If we add the slash to the path, we're in business: I'm closing this issue because no action needs to be taken in GeNet (but I will be fixing up some pipelines in Matesto...). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Problem
Our daily Matesto CI pipeline has been failing for the last three days. The failed step is always GeNet network simplification, which fails consistently in the same way since the most recent PR - which included some changes to
Dockerfile- was merged.The error from the Popper-managed pipeline looks like this:
Some Investigation
Manually running network simplification via the Docker CLI
Using the previous version of GeNet's Docker image
All good.
Using the current version of GeNet's docker image
The exact same command fails, apparently because GeNet cannot read the volume mounted into the container at
matsim12-test-town.Checking the default user inside the Docker container
It looks like changing the base image from
python:3.11.4-bullseyetomambaorg/micromamba:1.5.3-bullseye-slimin this PR has changed the default user inside the container.It seems likely that the problem is the failure of non-root users inside the container to successfully mount volumes on the host machine. Modifying the permissions on the directories on the host machine may be a viable workaround. It is also possible to override the default container user via the
--userparameter to the Dockerruncommand, but the Popper library we are using in Matesto does not provide a way to do the same thing programmatically.A quick fix would probably be to change the user in the
Dockerfile, but we will need to have a conversation about that if it was a deliberate decision to move away from the root user in the container.The text was updated successfully, but these errors were encountered: