Registries & Configuration

  • We needed a way, in our salt states:
    • To deduplicate the cumbersome handling of variables
    • To make cleaner jinja code
    • For a configuration knob, aggregate values from difference sources, by precedence.
  • For this, we decided to abstract this in python code
  • 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:
    • 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 3306
      • Nested Method: pillar/pillar.d/mysql.sls
          port: 3306
Last Updated: 2017-03-15