Add the ability to adjust timeouts for the api worker, report jobs, and data validation jobs. Also sets max content length and does not log requests by the kube probe that checks if the container is ready.
This also adds the JOB_BASE_URL config variable that can direct jobs to use another api vs the one where the job was enqueued. The idea is that the worker pod could have an API running as a sidecar container, and that API instance can be used instead of the main instances. Then we can adjust the timeouts for that sidecar API to be long and allow for job completion even with large posts/gets.
I also though about not using the APISession at all in the jobs like compute_report. But, the API provides a well defined interface, even if it does introduce more overhead vs direct database access, and the api and core code remain a bit more separated.
Add the ability to adjust timeouts for the api worker, report jobs, and data validation jobs. Also sets max content length and does not log requests by the kube probe that checks if the container is ready.
This also adds the JOB_BASE_URL config variable that can direct jobs to use another api vs the one where the job was enqueued. The idea is that the worker pod could have an API running as a sidecar container, and that API instance can be used instead of the main instances. Then we can adjust the timeouts for that sidecar API to be long and allow for job completion even with large posts/gets.
I also though about not using the APISession at all in the jobs like compute_report. But, the API provides a well defined interface, even if it does introduce more overhead vs direct database access, and the api and core code remain a bit more separated.