Compose: 1.5.0-rc2: Compose does not remove the network during rm

[dave-tucker]

$ docker-compose --x-networking up -d
Creating network "counter" with driver "bridge"
Creating counter_web_1
Creating counter_mongo_1

$ docker-compose --x-networking stop
Stopping counter_mongo_1 ... done
Stopping counter_web_1 ... done

$ docker-compose --x-networking rm
Going to remove counter_mongo_1, counter_web_1
Are you sure? [yN] y
Removing counter_mongo_1 ... done
Removing counter_web_1 ... done

$ docker network ls
NETWORK ID          NAME                DRIVER
d84962a207f8        counter             bridge
f60408bc3b3b        bridge              bridge
13a612e10bd7        none                null
517effa88694        host                host

After, rm I still have a network created with the project name
I would expect this to be removed

NOTE: This also causes an issue with Swarm that I will raise another issue for

[dnephin]

I don't think rm should necessarily remove the network. rm is exclusively for removing containers, it doesn't remove any images built with up either, and when we add support for named volumes, I wouldn't expect it to remove those.

I think we should consider doing this as part of the proposed docker-compose down command (#2277)

[dave-tucker]

@dnephin I don't think putting this in down would be the right solution

Engine already has flags in docker rm for handling volumes etc...

Usage:  docker rm [OPTIONS] CONTAINER [CONTAINER...]

Remove one or more containers

  -f, --force=false      Force the removal of a running container (uses SIGKILL)
  --help=false           Print usage
  -l, --link=false       Remove the specified link
  -v, --volumes=false    Remove the volumes associated with the container

Compose seems to be following this convention

Remove stopped service containers.

Usage: rm [options] [SERVICE...]

Options:
    -f, --force   Don't ask to confirm removal
    -v            Remove volumes associated with containers

As we create a network per project, I think it's ok that we delete it too.
It's also safe to do this by default, as there is no risk of losing data (unlike deleting a volume)

Proposal
Something like this would work. This would match my expection, that as a user, when I issue a "rm" it removes the containers and the network that was created for the project.

Remove stopped service containers.

Usage: rm [options] [SERVICE...]

Options:
    -f, --force              Don't ask to confirm removal
    -v                       Remove volumes associated with containers
    -n, --network=true       Remove the network associated with the project

If the users want's to keep the network around for whatever reason, they can docker-compose rm -n

[dnephin]

As we create a network per project, I think it's ok that we delete it too.

I agree, it's ok that we delete it, but I don't agree that rm is the right place to do so.

It's also safe to do this by default, as there is no risk of losing data

Is there any risk in leaving the network around?

We still leave images built by compose, because there's a command in docker-cli to remove them, and it really doesn't hurt to have an extra image. We may add a command to clean these up, but it's not really a highly requested feature.

Engine already has flags in docker rm for handling volumes

Right, but it doesn't have a flag for removing a network, because that wouldn't make any sense. You can remove a volume because 1) the volume is only being used by that one container, and 2) until very recently there was no other api for removing volumes. Now that we have a top level api to remove them, it's probably better managed explicitly using the new volumes commands.

I think it's a mistake to rush this and add it to rm which is completely unrelated to networks.

[arun-gupta]

I think reverse semantics for -n would be better. By default the container should be removed the container with rm -f. And only if users want to keep the network then they can specify -n which would be equivalent to --remove-false.

[schmunk42]

@dnephin

Is there any risk in leaving the network around?

I ran into errors like this:

Creating network "build11637" with driver "None"
failed to parse pool request for address space "LocalDefault" pool "" subpool "": could not find an available predefined network

I had several networks, each for every build left behind on our CI:

$ docker network ls | grep build
97c9fc99f9b5        build11590          bridge              
654e6c387d38        build11594          bridge              
5690c355e1fc        build11611          bridge              
83b1bf58a404        build11575          bridge              
d8a136713417        build11585          bridge              
ede77e84a10c        build11589          bridge              
4a8133a4bf52        build11563          bridge              
daf61484b71d        build11582          bridge              
cc9bc2d50565        build11613          bridge              
ebb7269c7a86        build11614          bridge              
90a2a868d521        build11579          bridge              
da13ed3d4f7b        build11576          bridge              
423e754545e7        build11570          bridge              
4f2e16b15487        build11591          bridge              
d9cd16ea5058        build11610          bridge              
0fb0a31b520f        build11616          bridge              
bbb35a3cbcc9        build11574          bridge              
d5b4d9cff806        build11593          bridge              
b014e86360ed        build11629          bridge              
2e14f3ee0cf2        build11631          bridge              
25c20171f9be        build11615          bridge              
6b3c9b172d6f        build11580          bridge              
2ba2519ee2f4        build11588          bridge              
9e16a476de94        build11612          bridge              
c0c2569fbd87        build11630          bridge              
67630ee308a6        build11573          bridge              
6f65f17c9f31        build11581          bridge              
834588ba0f49        build11572          bridge              
0a9baa340e4b        build11625          bridge   

I could only create new networks, after deleting old ones.

[dnephin]

@schmunk42 Thanks, that's good to know. How many networks did you have at this point? I wonder if this is a limitation with the backing cluster store.

We definitely want to provide a way to remove networks, but I still think doing it as part of a new command is the way to go. I'll add more details to #2277.

[schmunk42]

I just had the ones listed above, single VirtualBox docker-machine (docker 1.9.1).

[nenko-tabakov]

Hey guys,
I have the same problem using docker-compose for testing. I ended up with 27 networks before docker-compose failed to start.

Here is a sample script for removing them:

for i in $( docker network ls | grep build | cut -f1 -d ' ' ); do
docker network rm $i
done

Just replace "build" with proper name.

[bufke]

I still have this issue. docker-compose down does not fix it. I have 31 networks all with unique names. I run compose with a new name that does not match any of the 31 networks but get the "could not find an available predefined network" error. Deleting the excess networks fixes it. I used @nenko-tabakov script that I am just running periodically.

It's fairly reproducible with a CI environment where new builds happen often.

[mavenugo]

@bufke ts not limited to 31 networks. the predefined subnet pools are limited.
But one can always use the --subnet option and create many many networks without any limitation.

Compose v2 also provides the ipam option where you can configure your preferred subnets.

[ebmeierj]

I have the same issue on my CI server. I am limited to <10 networks however. @mavenugo could you please give a little more explanation on exactly what the limitation is here? Is this configuration or hardware related? What am I actually running out of in this case? I apologize, my understanding of what docker networking is actually doing behind the scenes is limited. I tried reading through https://github.com/docker/libnetwork/blob/master/ipam/allocator.go but it wasn't much help.

[ain]

Reproduced as well, the situation for me:

$ docker network ls
NETWORK ID          NAME                     DRIVER
39c8024241f2        20160509114606_default   bridge              
b0104200b67f        20160509114810_default   bridge              
91b7966928da        20160509134428_default   bridge              
d70d4dd7a2bb        20160509141646_default   bridge              
1917a8e7bda8        20160509141957_default   bridge              
ce1de6dfb850        20160509142206_default   bridge              
cb66f538e534        20160509145522_default   bridge              
fbe2a91a4226        20160509150412_default   bridge              
07c64453d5d2        20160509191511_default   bridge              
97fe195f66de        20160510000744_default   bridge              
b9743cd0eac4        20160510081354_default   bridge              
daebb3725de9        20160510083615_default   bridge              
ff1dc58d61c6        20160510092607_default   bridge              
91a16d966d2e        20160510095400_default   bridge              
3ebca5b19f0a        20160510111026_default   bridge              
a686b40d1efa        20160510111509_default   bridge              
f60b6371031b        20160510111633_default   bridge              
b8dc2f002561        20160510111828_default   bridge              
85b79de516ac        20160510112258_default   bridge              
9e4bba8e6433        20160510112412_default   bridge              
c969abed0d99        20160510112927_default   bridge              
af5f3b787779        20160510113253_default   bridge              
ded71054c16d        20160510153926_default   bridge              
1094922e803b        20160510171843_default   bridge              
046b697f9fd2        20160510173618_default   bridge              
32b1fab98d4a        20160517095008_default   bridge              
32cae3fc9c88        20160517145832_default   bridge              
61bd948a6e0c        20160520105055_default   bridge              
47ab00c1b738        20160520113359_default   bridge              
ce5f2980e85d        20160520152533_default   bridge              
4f27ddc9801e        bridge                   bridge              
d53edbc9e0ab        host                     host                
3d3d050ba84f        none                     null   

and corresponding error:

01 docker-compose -f docker-compose-staging.yml up -d
01 Creating network "20160523083936_default" with the default driver
01 failed to parse pool request for address space "LocalDefault" pool "" subpool "": could not find an available predefined network

Platform:

$ docker-compose version
docker-compose version 1.7.0, build 0d7bf73
docker-py version: 1.8.0
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013

$ docker version
Client:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Tue Apr 26 23:30:23 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Tue Apr 26 23:30:23 2016
 OS/Arch:      linux/amd64

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.4 LTS
Release:    14.04
Codename:   trusty

[ain]

My above-listed problem was eventually unrelated to docker-compose down, the removal works:

      01 docker-compose down
Stopping 20160523100010_web_1 ... done
      01 Stopping 20160523100010_db_1 ...
Stopping 20160523100010_db_1 ... done
      01 
      01 Removing 20160523100010_web_1 ...

      01 Removing 20160523100010_web_1 ... done
      01 

      01 Removing 20160523100010_db_1 ... done
      01 
      01 Removing network 20160523100010_default

Networks had remained from previous starts, so the question here is if there could be a way to automagically remove redundant networks that are up there for whatever reason, but not used.

[schmunk42]

Networks had remained from previous starts, so the question here is if there could be a way to automagically remove redundant networks that are up there for whatever reason, but not used.

@ain

At least for development, you can just remove all networks, like so:

docker network rm $(docker network ls -q)

Docker should complain about predefined and in-use networks...

Error response from daemon: bridge is a pre-defined network and cannot be removed
Error response from daemon: host is a pre-defined network and cannot be removed
Error response from daemon: none is a pre-defined network and cannot be removed
Error response from daemon: network phd_default has active endpoints
Error response from daemon: network testphd_default has active endpoints
Error response from daemon: network wigdets2tests_default has active endpoints

[ghost]

@mavenugo can you please provide example how you create your network per your previous comment

ts not limited to 31 networks. the predefined subnet pools are limited.
But one can always use the --subnet option and create many many networks without any limitation.

Compose v2 also provides the ipam option where you can configure your preferred subnets.

I still encounter this issue using

Docker version 1.10.3, build 20f81dd
docker-compose version 1.7.1, build 0a9ab35

and perform recovery via cleanup by invoking

docker network ls | grep -v `docker network ls --filter name=bridge -q` | awk '/bridge/{system("docker network rm " $1)}'

OR

docker network ls --filter name=xxxx -q | xargs docker network rm

OR after every build make sure afterwards to

docker network rm xxxx