Stopping a footloose container leaves the system in hard to recover state
felipefzdz opened this issue · comments
Context
I'm using Footloose as the base infrastructure for running platform tests through this Gradle plugin. That is supposed to run through automated testing being on CI or locally. As such, infra failures are expected and cleanup automation desirable.
Expected Behavior
If a docker container spin up by Footlose gets destroyed, not through Footloose, the tool should be able to easily recover from this situation on the next runs.
Current Behavior
After the crash, running another footloose create
doesn't actually do nothing as the state of container is not reflected.
Steps to Reproduce
footloose create -c config.yaml
INFO[0000] Creating SSH key: cluster-key ...
INFO[0000] Image: quay.io/footloose/ubuntu16.04 present locally
INFO[0000] Creating machine: cluster-node0 ...
footloose show -c config.yaml
NAME HOSTNAME PORTS IP IMAGE CMD STATE
cluster-node0 node0 22->58518,8180->8180,8888->8888 172.17.0.2 quay.io/footloose/ubuntu16.04 /sbin/init Running
Emulate a non managed by Footloose crash with this:
docker stop cluster-node0
cluster-node0
footloose show -c config.yaml
NAME HOSTNAME PORTS IP IMAGE CMD STATE
cluster-node0 node0 quay.io/footloose/ubuntu16.04 /sbin/init Stopped
As the state is Stopped, you might expect that running create
again would work. However:
footloose create -c config.yaml
INFO[0000] Image: quay.io/footloose/ubuntu16.04 present locally
INFO[0000] Creating machine: cluster-node0 ...
INFO[0000] Machine cluster-node0 is already created...
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Interesting enough if now I delete it from Footloose I get this:
footloose delete -c config.yaml
INFO[0000] Deleting machine: cluster-node0 ...
footloose show -c config.yaml
NAME HOSTNAME PORTS IP IMAGE CMD STATE
cluster-node0 node0 0->22,8888->8888,8180->8180 quay.io/footloose/ubuntu16.04 Stopped
So the STATE
is the same Stopped
but now the ports are displayed, that's somehow confusing.
Notes
Orthogonal to this, but motivated by this scenario, I've opened this other issue.