Describe the bug
While rqd.conf supports the DEFAULT_FACILITY tag, if rqd attempts to connect to a cuebot with a DEFAULT_FACILITY that is not defined on the cuebot host, it defaults to local. This was unexpected, and perhaps wrong?
Cuebot and RQD should be more aggressively denying host attachments to opencue if it's attempting to use a facility that isn't yet defined or know in cuebot with some active (and specific) error message at the startup of rqd.
Steps to Reproduce
in rqd.conf:
DEFAULT_FACILITY=aws-uswest2
RQD_TAGS=util
Then start rqd to any cuebot server which does not define this facility. It will attach (silently) to local.util.
Expected behavior
rqd should return an error once cuebot decides that the facility name isn't known to that cuebot installation. This error should include some general directions on how to add a facility and allocations to the cuebot server.
stevenparkerco3
commented
1 month ago
Describe the bug While rqd.conf supports the
DEFAULT_FACILITYtag, if rqd attempts to connect to acuebotwith aDEFAULT_FACILITYthat is not defined on thecuebothost, it defaults tolocal. This was unexpected, and perhaps wrong?Cuebot and RQD should be more aggressively denying host attachments to opencue if it's attempting to use a facility that isn't yet defined or know in cuebot with some active (and specific) error message at the startup of rqd.
Steps to Reproduce in rqd.conf:
Then start rqd to any cuebot server which does not define this facility. It will attach (silently) to
local.util.Expected behavior rqd should return an error once cuebot decides that the facility name isn't known to that cuebot installation. This error should include some general directions on how to add a facility and allocations to the cuebot server.
Version Number master