Skip to content
This repository has been archived by the owner on Sep 4, 2024. It is now read-only.

Implement a strategy for stale containers #20

Closed
agis opened this issue Apr 10, 2018 · 2 comments
Closed

Implement a strategy for stale containers #20

agis opened this issue Apr 10, 2018 · 2 comments
Labels
bug Something isn't working server
Milestone

Comments

@agis
Copy link
Contributor

agis commented Apr 10, 2018

Right now, we remove containers in StartContainer() after they run successfully. However, it might happen, for example in case of a mistry failure while a container was running (eg. SIGKILL), that containers are left around with nobody to remove them.

We should decide on how to treat such cases.

@agis agis added server bug Something isn't working labels Apr 12, 2018
@agis agis added this to the 1.0 milestone Apr 17, 2018
@agis
Copy link
Contributor Author

agis commented Apr 17, 2018

This also manifests itself in tests. If we stop a running test suite (Ctrl-C), it might happen that there are still containers left around, because they were created but never started. So when the tests run the next time, ContainerCreate() will fail since the container already exists.

A solution might be the following:

  • if ContainerCreate() returns an error, check if the error is because a container with the same name exists. If so, then just use it. If not, return the error. I believe we can do this since container names depend on the project files.
  • on boot, remove existing mistry's containers (namespaced)

I'm not quite sure about the 2nd point.

@agis
Copy link
Contributor Author

agis commented May 9, 2018

After some discussion, perhaps the simplest solution would be to remove the container if it exists.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working server
Projects
None yet
Development

No branches or pull requests

1 participant