reload fig.yml to mount the changed volumes

[japrescott]

When I build a container/service with fig and then later change the directory structure and adjust the volume mounts in fig.yml, my container always wants to mount the old directory. This happens also when I rebuild the container with the --no-cache flag.
Only way I have found to get the volumes to be updated is by removing all containers and their images (and the layers) and rebuilding. Interestingly, I've found that when I run the container with fig run [container] /bin/bash, the volumes are updated. Using fig up does not update the paths to the volumes.
I think this is a bug, but it very well could be that I am missing a point..

[aanand]

It's arguably a bug. When we recreate containers with fig up, we use VolumesFrom to make sure your data is carried over from the old containers. This doesn't mesh well at all with changes to volume configuration.

We might be able to compare the old container's volume configuration with the current state of fig.yml to see if we should leave out the VolumesFrom, but there are dangers there (it might result in the old volumes being discarded).

[d11wtq]

👍 we need to do something smarter around volumes. Have been bitten by this myself.

[oliland]

I use a bash script which builds fig files with different volumes depending on it's arguments, I guess this explains why my volumes are never removed.

[oliland]

Are there any known workarounds for this? I really don't expect any state to be carried over when I change my volume configuration.

[aanand]

@oliland: the current workaround is to remove the old containers with fig rm after you make changes to volume config.

[luan-cestari]

Got the same issue. It is very very hard to me to guess that it was this fig's issue, I tried many times just using docker and inspecting the containers to find the issue =/

[dnephin]

This feels like something that needs better support from dockerd to really fix correctly. I think moby/moby/issues/8363 is related. If the docker remote api supports more volume commands, it should be possible to handle these situations better.

[luan-cestari]

What if (for now) the fig build remove the containers? I think that would help a bit (it is not perfect but it would at least avoid people lost tons time to find the workaround )

[dnephin]

There are a few related issues here (at least #613, #622)

I suspect we can fix this in fig, but there are a lot of different cases to handle:

1. volumes_from changed
2. volumes changed
3. the contents of a data volume listed in volumes_from changed

There are workarounds for each of these (some combination of either fig rm or fig up depending on the issue), but they often take a while to figure out.

I like @aanand proposal of comparing the config to the config of the previous container, to determine if volumes_from should be used during the recreate (or not).

1. should be an easy comparison, does the config volumes_from match the inspect VolumesFrom of the existing container. If it doesn't match, don't add a "volumes_from previous container"
2. similar to 1, but it needs to handle host volumes vs local data volumes
3. compare the image id of the container pointed to by volumes_from to the current image id. If these have changed, create a new container for that image. This will discard the old volume, so maybe require a prompt with a --force-recreate-data-volume (or a better named) flag to allow that to continue without the prompt.