-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restart snapshotter gracefully even if there are running containers #151
Comments
I hava tried the latest master branch (containes the patch #134 ), but when I 'kill -9 ', and restart right now, the container still has err The follow steps reproduce the issue
|
Currently, you need to re-run containers too. And I agree with that the snapshotter needs to be able to gracefully restart even if there are running containers. |
Ok,I also think the ideal usage is when snapshotter restarts, the running containers can still run normally. |
@ktock can you describe what is required to do an update/restart to the snapshotter in a running cluster for instance? How do you do that today? |
Currently, we need to kill all containers running on that node before restarting this snapshotter and re-deploy these containers after the snapshotter restarts. One of the idea to solve this issue is spawning the FUSE server as a separated process instead of goroutine as done today. |
recently, I have tried containerd lazy load feature. stargz-snapshotter use fusefs to fetch file data on demand, and in fuse userspace handler, if file is cached locally, it will return directly, if not cached locally, it will fetch from docker registry.
my question is, if stargz-snapshotter restart abnormally or when upgrade, the fuse connections will break, so container process read will failed. Is there some good practice?

The text was updated successfully, but these errors were encountered: