(The name is just a random proposal; please use the one that fits better - keep in mind we're going to process audio and video here)
This deployment should be similar to the other shellbox deployments, but there's also some differences:
- We definitely need to revisit limits/requests here. Given we're always setting the number of threads for ffmpeg, we can predict how many cores we need per shellbox request. We will thus need overall enough CPUs to run videoscaling at the current maximum concurrency. So tot_php_workers = concurrency_webVideoTranscode + concurrency_webVideoTranscodePrioritized, and we need about ffmpeg_threads CPU per worker as request. This will most likely also need max_memory_per_transcode (currently, 4 GB) of memory per worker.
- We might need to adapt some numbers in the apache setup to support large files, and/or write size file limits
- This might become a very noisy neighbour in terms of i/o and cpu usage. It might be sensible to think of ways to reserve some k8s nodes to async payloads like this one, that don't need low latency.
- Timeout for requests needs to be set higher than the timeout we set for videoscaling jobs (so, 1 day)
Finally, we need to set up LVS for this shellbox installation as well - both for the long timeouts and for handling of large files.