As we discussed, a host group is like an "alias" for a set of machines. You can assigned a host to more than one group, but jobs sent to the group will only run on those machines. A cluster is a priority scheme that will allow a job to run anywhere there is an available machine, but it could get preempted by a job that has a cluster specification that matches the machine.
Since your customer wants to divide up the farm strictly so that jobs intended for machines assigned to a project can't run elsewhere (even if hosts are available), you'd use a groupThere are several ways to do this in Qube, but a best practice that we recommend is to use the worker's cluster and restrictions as outlined in How to use clustering for workers.
Essentially, you set a worker's worker_cluster and worker_restrictions to the same value, so that a worker:
- is in a particular cluster with worker_cluster
- will only accept job that are submitted into that cluster with worker_restrictions
Then, your users will submit jobs to that cluster by setting that job's cluster value to the name of the cluster; this job will have best priority on the workers in that cluster, but will be free to also run on hosts in other clusters (at a reduced priority).
If the job should only run on workers in that cluster, the user should also set the job's restrictions to the cluster name in which they wish the job to run.
Here's how I'd set up the qbwrk.conf: to have hosts A - D all be in the /project1 cluster, but hostC will only run jobs from that cluster.
| No Format |
|---|
# define the template, currently only specifies the cluster, but can be any combination of parameters [project1] |
...
worker_ |
...
cluster = "/project1" |
...
|
...
# all 4 hosts inherit from the "project1" template
[hostA] : project1
[hostB] : project1
# hostC inherits the "project1" template, but also sets the worker_restriction
[hostC] : project1
worker_restrictions = "/project1
[hostD] : project1 |