reggie_config

Reggie Config using Pillar Stack

Please see the pillar stack documentation for full details on how pillar stack works. The primary motivation for using pillar stack is so each file has full access to all previously loaded pillar stack data. Regular SaltStack pillar files can't easily access other pillar data, which can make it difficult to share settings like database passwords across files.

Files are loaded in the following order, with earlier files taking precedence:

hostname/init.yaml
hostname/role.yaml
event_year_environment/init.yaml
event_year_environment/role.yaml
event_year/init.yaml
event_year/role.yaml
event_environment/init.yaml
event_environment/role.yaml
event/init.yaml
event/role.yaml
environment/init.yaml
environment/role.yaml
init.yaml
role.yaml

Where:

• hostname is the hostname of the machine (e.g. onsite-staging.reggie.magfest.org)
• event is the name of the event (super, stock, labs, west)
• year is the year of the event (2018, 2019, 2020)
• environment is the server environment (prod, staging, load, dev)
• role is the role played by the server (db, web, scheduler, worker)

If a server has more than one role, the role files will be loaded sequentially.

For example, the database server for staging Super 2019 would load files in this order:

staging-db-01.reggie.magfest.org/init.yaml
staging-db-01.reggie.magfest.org/db.yaml
super_2019_staging/init.yaml
super_2019_staging/db.yaml
super_2019/init.yaml
super_2019/db.yaml
super_staging/init.yaml
super_staging/db.yaml
super/init.yaml
super/db.yaml
staging/init.yaml
staging/db.yaml
init.yaml
db.yaml

WARNING: Using the hostname of the machine is recommended ONLY for single-VM deploys. The problem with setting hostname-specific config on multi-VM deploys is that it requires you to know exactly which config options are necessary for which components. For example, web and worker VMs each have Reggie config options, but there's no documentation for which is which!

Data from any of the previously loaded files can be accessed using the Jinja stack variable, like this: {{ stack['reggie']['db']['username'] }}.

The init.yaml file in each directory should open with the following line:

__: merge-first

Unless you know what you're doing, any other files (like db.yaml) should NOT include the merge-first directive. This ensures the settings are merged in the correct order, and are available in any subsequently loaded file.