Open bcipriano opened 2 years ago
For logging, it would be interesting to add an HTTP endpoint to enable decoupling the GUI and the filesystem used by RQD.
For logging, it would be interesting to add an HTTP endpoint to enable decoupling the GUI and the filesystem used by RQD.
Great idea -- I've incorporated this into the ideas list.
We have a possible use case. We have cuebot
on GCP and few render Windows workers there too. Initial tests indicate that this woks fine, scaling to more should not be an issue. The machines and cuebot can see and connect to each other without a problem.
The issue comes when a local worker (right now for development purposes) comes. It's able to talk to the cuebot, registers itself, but cuebot can't talk back (due to our global firewall settings, and we don't want to change that).
I was wondering how people solved this? Proxy maybe? It also made me think for this special case, whether it won't be worth creating an additional grpc bidi stream (both ways) that can both talk to the cuebot, and cuebot can talk back and serve jobs. Understandigly this would means more pressure on the cuebot to keep that connection, so it'll be only useful if there a handful of such machines.
Anyone else run into something like this?
At the moment OpenCue is agnostic as to where resources run -- if RQD can run on a machine and that machine is networked to be able to reach the Cuebot, OpenCue doesn't really care where that machine is running. However, the TSC is currently discussing ways that cloud functionality can be expanded to be easier/more helpful to cloud users.
Major use cases
Easily deploy OpenCue on the cloud.
Easily scale RQD workers in the cloud. Help users make informed decisions about how many workers they need to complete their current OpenCue workload.
Easily deploy OpenCue in the cloud
Ideas:
Easily scale RQD workers in the cloud
Ideas: