4 ms·

Interesting. Will it be possible to control sweeper via API also? I'm a solo open-source maintainer and have a popular project that people want to orchestrate

Interesting. Will it be possible to control sweeper via API also? I'm a solo open-source maintainer and have a popular project that people want to orchestrate many instances of. Each instance (a.k.a session) is stateful and individually configurable. I'm excited to test out spawner. Any company that makes it super simple for open-source maintainers make money by providing a managed service will be a huge success - from my initial thoughts, this looks to fit the bill.

paulgb 5y ago
Is the use-case you have in mind for a Sweeper API being able to shut down a pod based on an external event? We don't have a nice HTTP API for that yet (you could go through the Kubernetes API), but only because I haven't gotten around to implementing it. Would that serve the use case you have in mind? If I can help with anything as you look into it, do let me know!
- 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 ago
    That 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 ago
      Here'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.
- smashah 5y ago
  If I understand correctly, Sweeper clears up sessions that haven't received a request in a certain amount of time. Essentially the use case would be to leave the session running until I ask Sweeper to clear it via an API request. Just to illustrate where I'm coming from, what I have so far mimics the pm2 cli as an API with built-in reverse-proxy, with create (similar to init), reload, restart, start, stop and delete.

paulgb 5y ago

Is the use-case you have in mind for a Sweeper API being able to shut down a pod based on an external event? We don't have a nice HTTP API for that yet (you could go through the Kubernetes API), but only because I haven't gotten around to implementing it. Would that serve the use case you have in mind? If I can help with anything as you look into it, do let me know!

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 ago
  That 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 ago
    Here'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.
smashah 5y ago
If I understand correctly, Sweeper clears up sessions that haven't received a request in a certain amount of time. Essentially the use case would be to leave the session running until I ask Sweeper to clear it via an API request. Just to illustrate where I'm coming from, what I have so far mimics the pm2 cli as an API with built-in reverse-proxy, with create (similar to init), reload, restart, start, stop and delete.