This needs to be able to support restarting the shim daemon without disrupting persistent API connections (Wait).
My current thoughts on how to handle this is to support multiple daemons running where when an admin needs to do something (such as upgrade the shim) the requests for currently running containers go to the old shim and requests for new containers goes to the new shim. This is a bit of a cheat, but is consistent with the normal operation of a shim.
Other possibilities are significantly more complicated and will likely require fd passing (currently unsupported in ttrpc) as well as some state transfer so that persistent requests can be moved.
This needs to be able to support restarting the shim daemon without disrupting persistent API connections (
Wait).My current thoughts on how to handle this is to support multiple daemons running where when an admin needs to do something (such as upgrade the shim) the requests for currently running containers go to the old shim and requests for new containers goes to the new shim. This is a bit of a cheat, but is consistent with the normal operation of a shim.
Other possibilities are significantly more complicated and will likely require fd passing (currently unsupported in ttrpc) as well as some state transfer so that persistent requests can be moved.