Salty Salt: Why do I dislike Salt after spending 1 day on it

General Discussion
1

Like:

  • Reaching a state means requesting something and also making sure things are really done.
  • Pillar helps me to avoid hard-coding secrets in the code

Dislike:

  • jinja mixed with yaml. It is like mixing macros and .ini config files. You see a bunch of % {{ things that look semi-python }} % and - name: {{ variable }}. You can also make for loops within yaml. I think those are actually macros…
  • it is not python. Why do I need to mix yaml for config and jinja for logic? Can I keep data and logic as separated as possible?
  • Pillar holds both user’s arguments and secrets and internal non-local variables…
    – It seems that pillar is the way to pass (global) variables between two parts of a workflow.
    – But that pillar thing also allows the user to pass arguments into the workflow, like ‘do you want to install fedora/debian’?
    – Mixing the internal and front-end seems wrong. It is like having a TV controller were some buttons are normal buttons but you have a hundred extra buttons that controls the internals: buttons that say 'connect/disconnect the power to transistor #113`.
  • how to document this thing?
  • how to test this thing without learning a bunch of other stuff?
  • ‘execution modules’ are pure python function / libraries. But I can’t find how can my custom function take yaml style arguments (e.g. ‘- name: install_tripwire’).

Since I don’t have a million qubes, I don’t need parallel execution/execution graph/out of order execution. I can use 1 function per step in the workflow and each step would call only 1 other step.

What do you think about Salt?

So far it leaves a bitter taste in my mouth. :frowning:

2
  • Salt is a mixture of Jinja (macro and programming logic that looks semi-Python), YAML (configuration mixed with call of builtin functions), and Python (reusable custom function/library).
  • In a single file, the user can mix and match Jinja and YAML… macro and logic in one sub-item of an item in the YAML is allowed.
  • I prefer to use only Python to implement reusable logic. I would keep configuration data and programming logic as separated as possible.
  • If you use Python to implement a step in your workflow, your Python script must output something that is equivalent to YAML (see salt.renderer.py)
  • Passing user input or variables from a step to another step involves setting / reading the values in one special dictionary, called Pillar. The programmer needs to be careful. Otherwise, he makes a ball of mixed up user inputs and internal variables. See the definition of pillars: Pillar Walkthrough
  • Testing Salt configuration requires learning a Python tool: nox
  • No document generator for the Jinja and YAML part of your configuration. You can use Sphinx for the Python part…
  • I think learning all these languages, tool, and discipline to not make a mess is a significant barrier to entry.