Volume driver reports as "changed" on second "libcompose up" attempt

[wagoodman]

Currently when attempting to run bring services up with libcompose, on the second attempt the Up command fails with Volume "node_modules" needs to be recreated - driver has changed.

The example docker compose file:

version: '2'

services:

  react:
    image: node:8
    networks:
      react-lan:
    command: yarn start
    working_dir: /app
    ports:
      - "3000:3000"
      - "4444:4444"
      - "9222:9222"
    volumes:
      - .:/app
      - yarn_cache:/home/node/.cache
      - node_modules:/app/node_modules

volumes:
  node_modules:
  yarn_cache:

networks:
  react-lan:

The issue looks to be here: https://github.com/docker/libcompose/blob/6bb86d53fa21f155e2daafa64796dbca61733df5/docker/volume/volume.go#L63-L65

It is assumed that there will be a known configured value for config.VolumeConfig.Driver, however, if no configuration is passed to this function, then no default value is provided (it remains an empty string):

https://github.com/docker/libcompose/blob/6bb86d53fa21f155e2daafa64796dbca61733df5/docker/volume/volume.go#L88-L93

Changing the volumes section does indeed fix the issue...

...
volumes:
  node_modules:
    driver: local
  yarn_cache:
    driver: local
...

...however, this is not desirable. Since it is very common to not require the volume driver to be specified directly in the docker-compose.yaml then it makes sense to only check for a change in driver only when comparing against a non-empty value.

Another solution to this would be to add a default to the config.VolumeConfig.Driver to the value of local somewhere here:

https://github.com/docker/libcompose/blob/a86fb3c8479894bbaed76a230ef5b35eb83338ac/project/project.go#L318

[xZero707]

I just encountered this with version 1.25.4 (From pip). Any progress with this? It's an old issue that remains unsolved.

---

If you have encountered it, the workaround is available in reference posted by @frafra, just above this comment.

[thaJeztah]

@xZero707 this is the repository for libcompose, a go-implementation of a library for handling compose-files; I think you might be looking for the docker compose issue tracker; https://github.com/docker/compose/issues

[xZero707]

@thaJeztah I'm sure it's libcompose as I encountered error inside portainer/portainer container which utilized libcompose for stack deployment.

I agree, however that docker-compose from pip has nothing to do with libcompose. Sorry about the confusion I've created. docker-compose on the host is not even used in a containers.

---

Also, to clarify; This bug is not in Portainer but in libcompose library as discussed here: https://github.com/portainer/portainer/issues/1989 https://github.com/tea-mo903/rpi-nas/issues/1

Anyway, libcompose is deprecated, so I suppose this discussion is pointless.