Support for something similar to Heroku's one-off Dynos

[noah-duncan]

Hey @collimarco , I really like the simplicity of this compared to the other open source PAAS's.

For my use case, I have a simple django app that's almost a perfect fit for this, but there's one complication. I need the ability to programmatically spin up containers for one-off tasks (running a meeting bot). Furthermore, when I deploy new code, the currently running containers for these tasks should NOT get restarted (because that would cause the bot to leave the meeting).

It looks like maybe I could do this by having a separate orchestrator container with the cuber CLI installed and call cuber run launch_bot.py programmatically from that container. But not sure about the deploy requirement, let me know if that's possible within cuber. Maybe it just needs a small custom tweak to the code.

[collimarco]

Probably you can use cron jobs (already supported by Cuber): every minute, check if there are new jobs to be executed (e.g. in the database) and then run them, otherwise terminate the job and do nothing.

[noah-duncan]

Ok, that's another option. If the bot takes an additional minute to join the meeting though, that will be noticeable to the end user, so an instantaneous approach would be preferable. What about the deploy issue though?

Furthermore, when I deploy new code, the currently running containers for these tasks should NOT get restarted (because that would cause the bot to leave the meeting).

[collimarco]

Maybe I don't understand exactly your use case.

Heroku's one-off dynos are used mainly for maintenance tasks:
https://devcenter.heroku.com/articles/one-off-dynos#use-cases

For that cases you can use cuber run:
https://cuber.cloud/docs/cli#cuber-run-cmd

Alternatively, you need to change your app to have shorter tasks (possibly idempotent) and you process them using background jobs (for example, for Ruby, we use Sidekiq). In this way, you will have short-lived tasks that save the intermediate states to a database and can be terminated and restarted easily. You can also give more time to these tasks to be completed:

# You can grant a longer grace period for shutdown (e.g. for long running jobs)
proc :slowjobs, 'bundle exec sidekiq -t 590', term: 600

[noah-duncan]

It's a pretty unique use case, so I wouldn't expect cuber to support it. In my use case, the one-off task is not for maintenance. It is going to maintain a bot's presence in a zoom meeting. If the process maintaining the bot's session in the meeting is terminated for any reason, the bot will have to ask to rejoin the meeting, so terminating the task and saving the intermediate state in the database is undesirable.

Do you think there's a way to tweak the code so that certain pods can basically ignore the shutdown command a deploy would trigger? Basically allow for a pod to say "I will not shut down to load new code, please let me run with my outdated code until my task is complete. After my task is done, I will shut down."