The advantage of the macro file format is the use of template inheritance and value replacement. A section is allowed to "inherit" another section's key/value pairs. This can be accomplished by adding a colon and a space-delimited list of templates.
(New in 6.9-1)
Currently, it supports the following two parameters, used primarily to optimize the loading time of qbwrk.conf:
During the loading of the qbwrk.conf file, if a section name like
In certain network setups, if the "name" is actually a qbwrk.conf template name or a hostname of a non-existent (offline or inaccessible) worker, this can slow things down quite a bit since each such lookup needs to time out. In those situations, the above two parameters, "templates" and "non_existent" in the
templates = centos,ubuntu
non_existent = render[071-100],render123,render155
worker_cluster = /projects/foobar
worker_cluster = /projects/secret
worker_groups = "dedicated"
In the example above, the section names "centos" and "ubuntu" are listed in the global_config's "templates" parameter, and also the
machines "render[071-100],render123,render155" are listed as "non_existent". The supervisor, when loading the qbwrk.conf file,
skips the IP address lookup for these listed names, thereby speeding up the process.
Note that in the example, it is assumed that the "non_existent" machines are not online, perhaps taken down for maintenance, and therefore
the site administrator has listed them there.
Also note that numerical range expansions are allowed in the value of the "non_existent" parameter (as in "render[071-100]"), to conveniently specify a contiguous chunk of hostnames.
As an example, let's say you need all machines to define proxy_account and proxy_password, you would then:
Then let's say you want to define a worker path map, but it will be different based on the OS, you would then:
Now let's say you want hosts01 - host05 to be in a group called "groupA" and a cluster called "/foo"; and host06 - host10 to be in a group called "groupB" and a cluster called "/bar", and then host11-15 need to be in group "groupB" and cluster "/bar" and define a worker_restriction of "/bar/+":
Now let's say that host07 is special and needs to be a member of both groupB and nvidia, but not lose its worker_cluster. Just redefine it afterwards (the file is read top to bottom):
Here's the whole thing together:
To pull it all together, if host12 were a windows machine, it would get the following config: