lmb
commented
4 years ago I'm glad it's useful :) Doing that will be really difficult I think.
From the POV of the library:
- How are you going to manage the old processes? What will enforce timeouts / maximum drain times?
- How can we ensure that unused Unix sockets are being cleaned up? With multiple processes is seems impossible to figure out when something is unused.
As someone deploying such an application:
- How many concurrent processes are the limit?
- If you expose metrics via a HTTP endpoint or similar you'll probably share this between processes as well. Which process gets to expose its metrics?
- How do you deal with bugs or vulnerabilities in old processes? How do you know which processes are vulnerable?
Ultimately, I think that the tableflip model isn't suitable for this. I guess you could build a separate process that holds sockets and spawns new versions of your service as you go along, but at that point you're reinventing systemd to a degree. I guess you could use tableflip to build this supervisory process if you wanted to.
I think tableflip is a great tool. I am experimenting the tool with a TCP server which handles long-lived TCP connections. When an upgrade is started, the old process needs to wait until all the existing TCP connections are done before the old process can exit. It can take a long time to drain the long-lived connections. As a result, a further upgrade is blocked until the old process exits. I wonder if we can have a way to relax this constraint?