Versions Compared

    Key

    • This line was added.
    • This line was removed.
    • Formatting was changed.
    Comment: Published by Scroll Versions from this space and version 6.9-0

    ...

    Expand
    titlePredefined Platform Sections

    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.

    Note

    The 'default' template is applied to all workers, regardless of operating system, and is inherited by every other template. So

    • [winnt]
    • [winnt] : default

    are equivalent.

    • [default]
    • [winnt]
    • [osx]
    • [linux]

    Example

    [linux]
    worker_cluster = /mylinuxboxes

    Expand
    titleTemplate Inheritance

    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.

    Icon

    The qbwrk.conf file is read from top to bottom. A template can only inherit from an already-defined template that appears before it in the file.

    Example

    The section:

    [qube]
    key9 = value00

    [section]
    key = value
    key1 = value1

    [section2] : section
    key = value3

    [section3] : section2 qube

    evaluates to:

    [qube]
    key9 = value00

    [section]
    key = value
    key1 = value1

    [section2]
    key = value3
    key1 = value1

    [section3]
    key = value3
    key1 = value1
    key9 = value00

    Expand
    titleWorking Example

    As an example, let's say you need all machines to define proxy_account and proxy_password, you would then:

    No Format
    [default] 

    ...

     

    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 qbwrk.conf file.

    Include+
    _worker_bootstrap_parameter_list_worker_bootstrap_parameter_list
    scrollPageId405BE23F014B092BED9A39737B3041D9
    
    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
    • We never had to inherit from [osx] or [winnt], as those were already applied to all OSX and Windows machines before we even got into [host*] sections.

    • There are no machines called "group*_rule" - those are just placeholders, if you will.

    • You can do all of this through WranglerView on the supervisor (you must be running it on the supervisor for this to work). Simply multi-select workers on the worker layout, right-click > "Configure on supervisor", then change all the parameters you choose and click OK. This is somewhat less flexible, but many people prefer GUIs.