...
- The Worker, which is a program that runs on every computer (also called a "host") on which you want to execute your jobs.
- The Supervisor, which runs on a dedicated machine, and keeps track of everything. It decides when a job runs, and which jobs run on which Workers.
- The Client refers to a number of interfaces that let you run actions from the command line, stand-alone GUI, and in-application submission GUIs (e.g. from Maya, 3ds Max, Nuke, etc.). Along with the commandline command line and GUI, there are also APIs (application programming interfaces) for Python, Perl, and C++ that provide the means to create custom actions.
- QubeWranglerView : (WxPython) (6.4+) WranglerView is the newly renamed Qube! GUI. This UI is aimed at advanced users, Render Wranglers and Admins.
- QubeArtistView : (PyQt) ArtistView GUI is designed to be a more artist-centric view of Qube! that delivers fast feedback on your rendering pipeline. QubeMobileView : (Python) Qube! MobileView is a light-weight webserver that serves up mobile-enhanced web pages from any machine in your facility. Note: Touch devices required for interaction . For example, we readily supply the following clients (among others):
- Qube UI (C++, New in 7.5): This is our main Graphical User Interface (GUI), intended as a replacement to our legacy GUIs.
- QubeLocker : (PyQt) QBLocker QubeLocker gives artists the ability to control how much of their workstation is available to the render farm and shows which jobs are running on their workstation at any time.
...
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". Windows" 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. Properties are different from resources because you can't "run out" of properties. For example, a machine is running Windows no matter how many jobs .Qube! also has the concept of land on it.
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 must also be reserved. The Supervisor looks for Workers that have those particular resources, and then reserves slots on them for the job(s) it wants to assign. Resources must be reserved because jobs use them up, and so you can run out of them.
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. Those seats are resources, and 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. So you require properties (at least 20 tables), but you reserve resources (4 seats).
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 ArtistViewthe Qube UI. 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.
...
See Also
Qube! Job Reference
Job Dependencies