...
The Job Slots (or Process Slots) for a Worker determine how many processes a given Worker can run at a given time. By default, the number of Job Slots is set to the number of processor cores, but this relationship is not required and can easily be changed so that the number of slots is different. For example, it is often desirable when using a multi-threaded renderer like Maya it's useful to have the Worker run 1 instance (or process) at a time, using all the cores for that instance - so that would be a single slot with 8 cores (on an 8-core machine). On the other hand, if we you want to run many single-threaded processes that each require a few resources, you may want to set the Worker to have 4 or 8 Job Slots available.
...
Jobs can be submitted with restrictions requirements, such as "only run on OS X" or "the processor must be at least 3GHz" . Requirements are statements about machine properties that must be available. Workers can also have restrictions on the number or kinds of jobs they will runrequirements; for example, a machine may be restricted required to running run only one After Effects job at a time.
Workers have consumable resources, such as CPUs and memory, that must be reserved by jobs. The facility may also have resources, such as software licenses, that jobs my specify as requirements. The Supervisor looks for Workers that have those particular resources, and then reserves slots on them for the job(s) it wants to assign.Qube! also has the concept
It may help to think of this in terms of restaurants. There are many restaurants in the city. You might require a restaurant that has 20 tables in order to host a wedding reception - any restaurant with 20 tables will do. On the other hand, let’s say a restaurant has 40 seats. You could reserve 4 of those seats for your party. While you are using them, they aren’t available to anyone else, which means there are only 36 seats available. As soon as you leave, those seats become available and the restaurant can again advertise that it has 40 seats available.
Workers can be organized into groups, which are sets of machines with an arbitrary label. A machine can only belong to multiple groups, and one way of steering jobs to machines is to specify a group to use. Qube! takes this idea one step further, with the notion of clusters. A cluster is a group of machines that is given a name. Clusters have a , but clusters are organized into a hierarchy, so that if a job cannot be run in one cluster, it may be able to run in a parent cluster, but with lower priority. The most common example of this is show/sequence/shot. If the appropriate resources are not available in the "shot" cluster, the job may be assigned to the "sequence" cluster, and so on.
Workers have resources, such as CPUs and memory, that jobs may specify as requirements. The facility may also have resources, such as software licenses, that jobs my specify as requirements. The Supervisor looks for Workers that have those particular resources, and then reserves slots on them for the job(s) it wants to assign.
Running the Job
Taking all the above into account, the job is assigned to a specific Worker. As that happens, there may be some path translation (for example, if the job was submitted from Windows but picks up on a Linux machine). The job's state will be changed from "pending" to "run". Assuming the job runs successfully, the state will change to "complete" and the logs it wrote will be available for viewing in both WranglerView and ArtistView. The images it created (if any) will also be viewable in those UIs. The Worker will advertise itself as available, and the Supervisor will look for another job to assign to it.
...