...
| Expand | ||
|---|---|---|
| ||
There are a few "special" section names that can be used for the different platforms. These will be associated with the Workers using the respective platform.
|
| Expand | ||
|---|---|---|
| ||
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. ExampleThe section:
evaluates to: [qube] [section] [section2] [section3] |
| Expand | ||
|---|---|---|
| ||
As an example, let's say you need all machines to define proxy_account and proxy_password, you would then:
|
...
| Info | |||
|---|---|---|---|
The following parameters are only settable locally on the Worker as they determine where the Qube! installation is located, the hostname of the Supervisor, and the filtering field for network communication. They will not have any effect when used in the Include+ | | _worker_bootstrap_parameter_list | _worker_bootstrap_parameter_list |
| scrollPageId | 405BE23F014B092BED9A39737B3041D9 |
proxy_account = render
proxy_password = cbda878cd5ad5dcdab8967dbc86bc786a857ada57bc # < - generated by qbhash |
Then let's say you want to define a worker path map, but it will be different based on the OS, you would then:
| No Format |
|---|
[osx]
worker_path_map = {
"\\" : "/",
"X:/project" : "/Volumes/xsan/project",
"H:/" : "/home",
}
[winnt]
worker_path_map = {
"/Volumes/xsan/project" : "X:/project",
"/home" : "H:/",
"/" : "\\",
} |
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/+":
| No Format |
|---|
[groupa_rule]
worker_groups = groupA
worker_clsuter = /foo
[groupb_rule]
worker_groups = groupB
worker_cluster = /bar
[host[01-05]] : groupa_rule
[host[06-10]] : groupb_rule
[host[11-15]] : groupb_rule
worker_restriction = /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):
| No Format |
|---|
[host07]
worker_groups = groupB,nvidia |
Here's the whole thing together:
| No Format |
|---|
[default]
proxy_account = render
proxy_password = cbda878cd5ad5dcdab8967dbc86bc786a857ada57bc
[osx]
worker_path_map = {
"\\" : "/",
"X:/project" : "/Volumes/xsan/project",
"H:/" : "/home",
}
[winnt]
worker_path_map = {
"/Volumes/xsan/project" : "X:/project",
"/home" : "H:/",
"/" : "\\",
}
[groupa_rule]
worker_groups = groupA
worker_clsuter = /foo
[groupb_rule]
worker_groups = groupB
worker_cluster = /bar
[host[01-05]] : groupa_rule
[host[06-10]] : groupb_rule
[host[11-15]] : groupb_rule
worker_restriction = /bar/+
[host07]
worker_groups = groupB,nvidia |
To pull it all together, if host12 were a windows machine, it would get the following config:
| No Format |
|---|
proxy_account = render # from default
proxy_password = cbda878cd5ad5dcdab8967dbc86bc786a857ada57bc # from default
worker_path_map = {
"/Volumes/xsan/project" : "X:/project",
"/home" : "H:/",
"/" : "\\",
} # from [winnt]
worker_groups = groupB # from [host12] ( [host[11-15]] ) which inherited from [groupb_rule]
worker_cluster = /bar # from [host12] ( [host[11-15]] ) which inherited from [groupb_rule]
worker_restriction = /bar/+ # from [host12] ( [host[11-15]] ) |
| Info |
|---|
|