Should the Docker provider remove the deployed containers on failure?
When deploying using the Docker provider, you may run into the issues of a container already being deployed on a current port.
Unfortunatley, even if it fails, the containers you deployed up until that point are lingering on.
Should the Docker provider go through all the deployed containers thus far and remove them? Or is this too dangerous?
we will be adding some tooling around "removing" containers sometime soon as part of https://github.com/projectatomic/atomicapp/pull/308 .. Let's revisit after we have the full lifecyle in place..
We may decide that if a part of it fails then it is reasonable to have the user do a clean or equivalent before they start to run it again.
It's a generic problem, and not just for Docker. As we had already discussed in the past, IIRC, deployments should be atomic. If the deployment of a component fails, we should rollback the deployment of any other deployed component.
@cdrage this is also #319
Ok let's get it in for GA then
This issue should be renamed to Atomic deployments, I think :)
Fixed in #456
Removing the blocker label from this. We won't be doing this before GA for several reasons.
- #456 is a risky change that is a "nice to have"
- There are issues with removing a docker container from within atomicapp prior to docker 1.9