3 ms·
I don't know about the GP, but I would actually like to be able to keep the pod alive while it's doing some processing, in case the user wants to run a long pro
by mwcampbell 5y ago
I don't know about the GP, but I would actually like to be able to keep the pod alive while it's doing some processing, in case the user wants to run a long process, go away, then come back later when it's done. Yes, I know there are other tools for orchestrating pure batch jobs, but I imagine some applications are a mix of interactivity and long-running computations.
- paulgb 5y agoThat makes sense. We currently don't support that directly, although we have a “grace period” which is how long it waits for a service to be idle before shutting it down. You could set to a very high number and then have the service manage its own termination when it became idle. But that's a bit of a hack, first-class support for that use case is something I'll think about.
- mwcampbell 5y agoHere's one way you could implement first-class support for this use case. It's a bit of a hack, but it's simple. IIUC, the proxy is a sidecar, meaning it runs in the same network namespace as the main container. So the proxy could listen on a particular port on localhost, and as long as a connection is open to that port, the sweeper wouldn't touch that pod. Then the main container would just need to open a TCP connection for the period of time that it wants to make sure it stays running.