Is your feature request related to a problem? Please describe.
There are users who want simpler tasks run every so often, and while they can just spin up a micro instance to manage it for them, that is overhead that could be lessened and improved upon. This is why I propose a condition-based time-based scheduled task system on Akash.
Describe the solution you'd like
A script should be able to check if the tenants' conditions for starting their task are met, from which it will be run for a set amount of time. With a default official time-based script, this is as easy to get price bids on as you only calculate how much of the day a deployment is running compared to the full 24 hours, and multiply that with the original cost. The pods will only run during these timeframes, and will be shut down the remaining time.
See this example for 6mh (6 minutes per hour) for a deployment traditionally costing 14 uakt. Note that this is simplified, persistent storage should be calculated seperately from this, as should be kept across boots:
full cost = 14 uakt/block
time of day = ( 6 * 24 ) / 1440 = 0.10 =>
new cost for 6mh = full cost * time of day = 1.4 uakt/block
Providers could also charge a flat rate for every startup:
full cost = 14 uakt/block
cost per start = 50 uakt
starts per day = 24
~ blocks per day = 13736
additional cost = (starts per day * cost per start) / blocks per day = 0.087 uakt/block
time of day = ( 6 * 24 ) / 1440 = 0.10 =>
new cost for 6mh = full cost * time of day + additional cost = 1.487 uakt/block
Time codes would have to be very flexible to support as many tasks as possible, e.g.:
X time units runtime, Y random or spread-out times, every Z timeframe or unit
5 minutes runtime, 2 times any time during this timeframe, between 14:00 => 5m2r14001800CET
the same but spread out evenly during this timeframe => 5m2s14001800CET
the same but one during the day, and one during the night => [5m2s14001800CET], [5m2s04000800CET]
5 minutes runtime, once per this timeframe, every hour (by default: first runtime when deployment is first run) => 5m1s1h
I'm sure you can improve on these timecodes, but the user must be able to understand them and they must be very flexible.
Additional context
This default time-based script would allow for tasks such as these to run on Akash:
Scrapers running at intervals
Game servers only needed at a few hours per day for friend groups
Services only needed at a few days per week for companies
Scaling up/down services automatically depending on time of day
Other non-official condition-based scripts could be:
On website update, useful for GitHub actions or similar services
On low provider usage, useful for giving the provider a way to turn on miners or other services that can run at any scale at a lower cost whenever there is low usage, giving them stability in idle earnings
If electricity costs are low at a time, run miners or other services that can run on any scale.
^^ one issue with other scripts is that it's hard to calculate costs, it's not as easy as just "multiply by the normal resource cost". Here, providers could charge for a maximum number of times they will run the task for every day, week, or month.
^^ one issue with this solution altogether is if a task must be done at a certain time, it may have some inconsistency because of startup times. This should be done by the user, and have them wait until the precise time for their scraper or whatever to run.
Is your feature request related to a problem? Please describe. There are users who want simpler tasks run every so often, and while they can just spin up a micro instance to manage it for them, that is overhead that could be lessened and improved upon. This is why I propose a condition-based time-based scheduled task system on Akash.
Describe the solution you'd like A script should be able to check if the tenants' conditions for starting their task are met, from which it will be run for a set amount of time. With a default official time-based script, this is as easy to get price bids on as you only calculate how much of the day a deployment is running compared to the full 24 hours, and multiply that with the original cost. The pods will only run during these timeframes, and will be shut down the remaining time.
See this example for
6mh(6 minutes per hour) for a deployment traditionally costing14uakt. Note that this is simplified, persistent storage should be calculated seperately from this, as should be kept across boots:Providers could also charge a flat rate for every startup:
Time codes would have to be very flexible to support as many tasks as possible, e.g.:
Additional context This default time-based script would allow for tasks such as these to run on Akash:
Other non-official condition-based scripts could be:
^^ one issue with other scripts is that it's hard to calculate costs, it's not as easy as just "multiply by the normal resource cost". Here, providers could charge for a maximum number of times they will run the task for every day, week, or month.
^^ one issue with this solution altogether is if a task must be done at a certain time, it may have some inconsistency because of startup times. This should be done by the user, and have them wait until the precise time for their scraper or whatever to run.