OK looking at our code, -m is used in querying bjobs and not during the submit, but you can add the -cluster argument in the submit.yml.erb as you’ve indicated. I believe this is the only solution for controlling where jobs are sent.
Can you deploy 1 OOD instance with 3 cluster configurations instead of 3 instances with 1 cluster config? It seems you’re deploying OOD on login nodes, maybe it’s more appropriate to give OOD it’s own VM as that’s generally the deployment strategy. This OOD VM should then be able to communicate with all clusters. This is the route I would suggest.
I believe you will only have collisions if you have colliding configs (i.e., /etc/ood/config/clusters.d/rka.yml on more than 1 instance. This will create jobs with cluster_id = rka on every instance it’s on, and so you have collisions). So the configuration file names and their contents need to be unique across deployments if you are deploying multiple separate instances. I believe if deployment on rid finds a cluster_id = rka it should simply ignore it becuase there is no cluster for rka on that node (there is no clusters.d/rka.yml on the rid host). This should be the behavior. Can you confirm this is the case, that you’re getting collisions because all instance configurations share the same filenames?
You can change the location of these files by using a different OOD_DATAROOT as described in this topic. Though I would leave this as a last possible resort. The uniqueness of each deployment is going to become untenable over time and likely confusing to your users, so I would suggest exploring 1 deployment with 3 unique configurations especially as 1.8 (the next release) rolls out because in that version apps can support multiple clusters.