Registries & Configuration

• To deduplicate the cumbersome handling of variables
• To make cleaner jinja code
• For a configuration knob, aggregate values from difference sources, by precedence.

So, a registry in the Makina-States vocabulary is a salt execution module that returns a python dictionnary:

• containing various configuration knobs
• with sane defaults
• overridable at will by the user via the pillar or the grains.

The idea was then to use dedicated saltstack execution modules to provide a way to have dictionnaries of data aggregated with this precedence:

• Pillar (pillar)
• Grains (grains)
• Configuration of the minion (opts)
• Configuration of the minion (opts[‘master]’])
• Exemples:
  • mc_apache
  • mc_nginx
  • mc_mysql
• Those registries rely on an heavily used function mc_utils.default that will do the job of gathering for the configuration prefix all the knobs from the various pieces of data we want (pillar, grains, opts)

Thus, by example, you want to install the mysql service:
You will use this sls:

  bin/salt-call -linfo --retcode-passthrough \
    state.sls makina-states.servies.db.mysql

Reading the code of mysql formula, you see that it calls mc_mysql

• To override the port (default: 3306), you can do this in the pillar or the grains those ways

  • Flat Method(preferred): pillar/pillar.d/mysql.sls

   makina-states.services.db.mysql.port: 3306
  

  • Nested Method: pillar/pillar.d/mysql.sls

   makina-states.services.db.mysql:
      port: 3306