re: bug introduced by update to docker-compose: go...
# contributing-to-airbytec
charles
10/15/2020, 5:29 AM
re: bug introduced by update to docker-compose: got to a place where i could get the app running in dev one time with the named volumes, but can’t get it to start a second time without having to clear out all the volumes first. will pick it up again tomorrow.
u
user
10/15/2020, 3:08 PM Copy code
ERROR: Configuration for volume dev-local specifies "device" driver_opt /tmp/airbyte_local, but a volume with the same name uses a different "device" driver_opt (/host_mnt/private/tmp/airbyte_local). If you wish to use the new configuration, please remove the existing volume "dev-local" first:u
user
10/15/2020, 3:08 PMit seems like the issue is that compose is not resolving the path of the volumes properly on the second try to it thinks the volume is misconfigured.
u
user
10/15/2020, 3:09 PMthat’s my current hypothesis anyway and is somewhat inline with some of the changes we saw in compose. though haven’t nailed down exactly what line this would have happened on.
u
user
10/15/2020, 3:34 PMthis theory seems correct.
u
user
10/15/2020, 3:35 PMif i:
• start from scratch
• create the named volumes with device:
/tmp/airbyte_local/host_mnt/private/tmp/airbyte_localu
user
10/15/2020, 3:36 PMobviously this isn’t really workable so still need to find a solution.
u
user
10/15/2020, 3:36 PMbut i think the mechanics of what’s going on here are starting to make sense.
u
user
10/15/2020, 3:36 PMgoing to submit an issue to the docker compose people to see if they won’t help.
u
user
10/15/2020, 4:02 PMu
user
10/15/2020, 4:04 PMI’m a little confused how this isn’t already reported though. It seems like named local volumes are just entirely broken.
u
user
10/15/2020, 4:11 PMseems like we should go with what jared mentioned and see if i can just get it working without using named volumes.
u
user
10/15/2020, 4:11 PMwill pick this up when i get back, but have to head to paint store now for a bit.
10 Views