Open soxofaan opened 1 month ago
cc @HansVRP
Perhaps it would be better to limit the job runtime instead of the job cost?
We have seen that runtime is a pretty good indicator of job costs, however it scales differently for every process graph.
Usually with some initial trial and error you do have an idea of how long your job is allowed to last. When it runs longer it is either unoptimized, there is a scaling issue or a problem in fetching the information.
The required information is already available since we do track the job status...
Note that this ticket is about the existing "budget" field in the openEO API, which is strictly about currency/credits, so it's a bit out of scope to involve run time. Moreover, with run time you have the same problems as originally stated: how to predict it, and if it can not be predicted, is it ok to abort a job that exceeds a limit and still charge for it?
FYI related discussion about run time limits:
When creating a batch job, there is a field
budget
described as:Some questions and discussion points:
budget
? E.g. In the python client we support thebudget
field when creating a job, but it's confusing when that is not being honored by the backend. It would be better if we can warn/error about that client-side.