compose: The error "ERROR: network network_main_net id ... has active endpoints" isn't particularly useful and blocks `docker-compose down`
Description of the issue
The error “ERROR: network network_main_net id … has active endpoints” isn’t particularly useful and blocks docker-compose down.
Details
I have multiple docker-compose.yml files that look like this:
version: '2.3'
services:
someservice:
networks:
- networks_main_net
...
networks:
network_main_net:
name: network_main_net
So far, this is the only way to have a shared network over multiple docker-compose.yml groups which doesn’t involve some hackery with a special network-owning folder that needs to be uped first.
However, for all of those containers, docker-compose down && docker-compose up -d is broken:
# docker-compose down && docker-compose up -d
Stopping mail ... done
Removing mail ... done
Removing network network_main_net
ERROR: network network_main_net id 6aaf7ec207e435452261aa3f408813c1197d5a5080288d70e4886373427c9fe7 has active endpoints
Since the error isn’t actually useful to me and certainly not something I would want it to abort over (of course there are still active endpoints - that’s the point of sharing the network!) I suggest that it is converted into a warning.
Context information (for bug reports)
# docker-compose version
docker-compose version 1.21.2, build a133471
docker-py version: 3.3.0
CPython version: 3.6.5
OpenSSL version: OpenSSL 1.0.1t 3 May 2016
# docker version
Client:
Version: 17.12.1-ce
API version: 1.35
Go version: go1.10.1
Git commit: 7390fc6
Built: Wed Apr 18 01:23:11 2018
OS/Arch: linux/amd64
Server:
Engine:
Version: 17.12.1-ce
API version: 1.35 (minimum version 1.12)
Go version: go1.10.1
Git commit: 7390fc6
Built: Wed Feb 28 17:46:05 2018
OS/Arch: linux/amd64
Experimental: false
Steps to reproduce the issue
- Use shared network alike to
networks.some_name.name: some_name(used by a container asservices.myservice.networks: ["some_name"]as shown above) - Set up 2+
docker-compose.ymlgroups that all share this same network name - Do
docker-compose up -dfor all the groups sharing this network - Do
docker-compose downon one of them
Observed result
error message that isn’t particularly surprising or relevant, and exit code non-zero
Expected result
warning (or no network-related output at all) and exit code 0
Stacktrace / full error message
Removing network network_main_net
ERROR: network network_main_net id 6aaf7ec207e435452261aa3f408813c1197d5a5080288d70e4886373427c9fe7 has active endpoints
Additional information
Ubuntu 18.04 LTS
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 16 (1 by maintainers)
I’m not sure what to say ; there is a solution, but your answer seems to be “I don’t want that solution, it forces people I work with to learn a new thing, I want you to break the thing we use currently so that it works for our setup.” I want to engage with this honestly, but it seems to me you’ve placed this artificial roadblock of “human politics” that’s probably not that hard to solve. If we can get monkeys to learn sign language, getting a handful of educated individuals to learn a new subcommand should be doable. Or, you know, just write a script that does the thing for them.
The concept of a shared network exists, but it involves using the
externalkeyword and recognizing that one part of the stack has to own that resource. In the typical example you cite, that’s probably the Compose file that declares the proxy, since it’s the one that always needs to be present for the system to function. It makes sense in practice too ; you won’t be able todocker-compose upanything else until the proxy is up and running (creating the network), and you’ll be able todocker-compose downany part of the stack without getting error messages. That’s not hackish, it’s just good ops hygiene.This to me is the core of the problem. Breaking fully automated startup is not a slight inconvenience, but a major problem. I shouldn’t need a custom shell script to hard code dependencies to make stuff create & launch properly, this is what docker & docker-compose are already for. It’s their entire purpose not to require me to do this to get my deployment to work!
Edit: at least that’s my opinion on things, hopefully should explain to you why I keep bringing up those tickets
You’re just reiterating the limitations of the concept… your “advantage”/“correct approach” simply means that start order suddenly matters in a frustratingly opaque way that breaks deployments if the administrator is not deeply aware of hidden dependencies.
What I did was simply use the best solution to this I’m aware of - suggested to me, by the way, I didn’t make it up myself - to try to define a shared network properly. I made this ticket because it doesn’t work nicely. That should change.
The whole concept of “one folder needs to own the resource” is simply bad in some scenarios. It may be good for some use cases, but it simply isn’t for others. Is that so hard to understand? Why can’t docker-compose support those other use cases better as well? Why does the basic need for this need to be discussed over an over, when it’s obvious that those use cases aren’t well supported, and people have them?
It’s just frustrating to constantly get back into concept discussions. The use case is super simple, why people need it is also super simple. I suggested one way, there are also others of course. Quite frankly, I don’t care how this is done, this was just one way this could be improved since I don’t see much other ideas floating around, just constant responses of “but we can’t do that either”. (Sorry, I don’t mean to attack personally - just explaining why I’m getting frustrated over here!)
Edit: also see #4179 which was closed by the way suggesting this works fine. It doesn’t. Hence this ticket here