test runner: check if the service network already exists

[mtojek]

While investigating issues locally it's annoying to remove the service network, because it blocks next tests from execution:

➜  zoom git:(pkg-changelogs-1) elastic-package test system --data-streams webhook -v
2021/02/17 10:57:05 DEBUG Enable verbose logging
Run system tests for the package
2021/02/17 10:57:05 DEBUG setting up service...
2021/02/17 10:57:05 DEBUG setting up service using Docker Compose service deployer
2021/02/17 10:57:05 DEBUG running command: /usr/local/bin/docker-compose -f /Users/marcin.tojek/go/src/github.com/elastic/integrations/packages/zoom/_dev/deploy/docker/docker-compose.yml -p elastic-package-service up --build -d
elastic-package-service_zoom-webhook-http_1 is up-to-date
Starting elastic-package-service_zoom-webhook-https_1 ... done
2021/02/17 10:57:06 DEBUG attaching service container elastic-package-service_zoom-webhook-https_1 to stack network elastic-package-stack_default
Error: error running package system tests: could not complete test run: could not setup service: could not attach service container to the stack network (stderr="Error response from daemon: endpoint with name elastic-package-service_zoom-webhook-https_1 already exists in network elastic-package-stack_default\n"): exit status 1

[ycombinator]

We should probably have the test runner pessimistically remove the network at the start of the run before it recreates it.

[mtojek]

It depends whether or not there are live containers assigned. I don't expect the service network to be manually tweaked, but if developer decides to temporarily change its settings, recreating will block such experiments.

[ycombinator]

Hmm, fair point. Agreed to just check for existence and not create the network if it already exists.

[mtojek]

I think this issue isn't valid anymore in standard workflow, so I guess we can close it.

[CallumDowling]

Still an issue for me v0.77.0

[jsoriano]

@CallumDowling do you have reproduction steps?

[CallumDowling]

@CallumDowling do you have reproduction steps?

@jsoriano I fixed it by;

1. docker kill $(docker ps -q)
2. docker container prune
3. docker network prune

Not sure which one of 2/3 fixed it, now I can't reproduce - sorry. Similar things have happened in the past where docker system prune -a worked. elastic-package might need more checks / cleaning up old resources like @ycombinator comment, maybe a flag?

[jsoriano]

Ok, I will reopen this issue, to make elastic-package more resilient to spurious network resources from previous executions.