Job and Worker Restrictions
Restrictions are used to allow or restrict where jobs run, and are applied to both jobs and workers. Restrictions are based on cluster names, but differ from the clusters themselves by an important difference:
Jobs and workers can belong to 1 and only 1 cluster, but can be restricted to none, 1, or several clusters
This seems a bit hard to fathom, until you remember that a job has preferential priority on a worker whose cluster matches the job's cluster, but the job is free to run on any host in other clusters. The job's restriction value can be used to limit what other clusters the job could possibly run on.
Restrictions defined for jobs
When a job has a restriction defined, it means only run on hosts that satisfy the restriction expression. Hosts that don't satisfy the restriction expression won't be considered as dispatch candidates (the job will never be sent to that worker).
Restrictions defined for worker hosts
Restrictions Syntax
A restriction is really defined as a "filter" for hosts based upon information in the queuing algorithm; the values are one or more cluster names. In the priority/cluster queuing system, a user specifies their restrictions by directory structure format:
/[<segment>/][<segment>/][+|*]
- + means all hosts at that level and below in the hierarchy.
- * means only hosts at that level.
Worker Restrictions Example
Accept jobs in /hello/world, but do not include lower levels:
/hello/world
Accept jobs in /hello and all levels below:
/hello/+
Accept only jobs below /hello/… but not including /hello:
/hello/*
Accept jobs in /hello or /goodbye:
/hello || /goodbye
Job Restrictions Examples
Run on workers in /hello/world, but do not include lower levels:
/hello/world
Run on workers in /hello and all levels below:
/hello/+
Run on workers only below /hello/… but not including /hello:
/hello/*
Run on workers in /hello or /goodbye:
/hello || /goodbye