-
Notifications
You must be signed in to change notification settings - Fork 260
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature]: Use cases and design of a shuttle-crond service #909
Comments
The above sketch was based on the example and took the form of a service. This is how it could look like as a resource that allows interacting with spun up jobs at runtime.
|
Here's a another sketch that @chesedo came up with a while back. |
To keep this conversation going, I implemented a first version of the above in an external repo, https://github.com/morlinbrot/shuttle-crond, among other things to explore how community-maintained extensions to shuttle may work. I'd like to put up two things for consideration: On external extensions of shuttleOne thing that doesn't really yet fit with this idea is that when implementing
On crond functionalityMy implementation is quite simple and does provide ways to interact with spawned cron jobs by returning a
Let me know what you think! |
If jobs are taken down on restart, then there is no reason to have the ids persist across runs, so this example use case could perhaps use an in memory collection? Otherwise the design of the resource feels mature enough to implement. |
True, that was just a quick first sketch I did. With my last comment, I actually wanted to draw attention to the actual implementation I did where I'm not persisting IDs but simply work with thread handles: https://github.com/morlinbrot/shuttle-crond As you can see there, the |
I think Some use cases might also want a The fact that the crond is moved to a tokio task in shuttle::main makes it feel like this service is not a resource, but more of a recipe 🤔 |
This way we would create a dependency on the Additionally, I would argue that the user-facing API is much simpler like this which I would consider to be an explicit design goal, e.g. making this resource a quick and simple "fire-and-forget" solution to scheduling some tasks. |
|
Hm, yea, but that would still couple us and the user to a specific crate. I really prefer the simple option of just passing a string schedule, after all that is how you interact with cron in general (Btw, obviously the
That could be kind of neat, I will have a look into that! |
Closing in favour of #1550 |
Describe the feature
Issue to discuss the idea of adding some form of "demon-as-a-service" cron functionality to shuttle, e.g. a
shuttle-crond
service or resource.Following the discussions sparked by this first implementation which we decided to rename to
request-scheduler
and move to the shuttle-examples repo, thereby closing this original issue, we settled on the following for now:Design of a
crond
service or resourceAny implementation of a
shuttle-crond
service or resource should provide a way to run any user provide logic directly (not by calling a URL). It shouldShuttleRuntimeContext
with resources likesecrets
,persist
, etc. This should be handled by the users themselves.This could become an example of a community maintained extension of shuttle.
See below what a
shuttle-crond
could look like based on @jonaro00s and my first sketches.Future angles to explore
During the discussion it was brought up that it might also be really useful for shuttle to provide a more generic way of running workloads.
A natural evolution that of the
shuttle-crond
idea would be to provide something similar like k8s' cron service spinning up pods or some other way for the user to provide binaries, containers or WASM modules via a manifest file.@jonaro00 already started exploring the idea of being able to install native packages in the shuttle environment that the user could then access in their workloads.
I think there is a lot of design space to explore here with a number of different possible outcomes. As a starting point, I would love to hear some opinions of the shuttle team on which use cases may be worth exploring and what a possible end product should look like.
Suggestion or Example of how the feature would be used
shuttle_crond
Usage
Duplicate declaration
The text was updated successfully, but these errors were encountered: