CODEWITHSUNDEEP
salt-project
muffel
muffel

Reputation: 7360

winding-up dynamic states in Salt for changed environments

Consider some dynamic state shapes based on certain grain / pillar values. A webserver could for example add additional site definition for debug endpoints:

{% if grains['dev'] %}
/etc/nginx/sites-enabled/logaccess.conf:
  file.managed:
    - source: salt://some/path/logaccess.conf
{% endif %}

this works fine unless for example a dev server changes its role and becomes a productive one. There is no state left, and the file resides on the minion.

I could of course add a counterpart

/etc/nginx/sites-enabled/logaccess.conf:
{% if grains['dev'] %}
  file.managed:
    - source: salt://some/path/logaccess.conf
{% else %}
  file.absent: []
{% endif %}

which is ugly and doesn't work for e.g. packages (not requiring a software installation for a particular state doesn't always it is not required by another one or installed manually on purpose).

How do I properly handle changes of those states and and eventual winding-up of created artifacts, installed software etc?

Upvotes: 1

Views: 86

Answers (1)

lakier
lakier

Reputation: 580

In fact you are asking: "does the Salt support state rollbacks?"

The answer is no, but the states themselves often offer some kind of "rollback", e.g. file state can restore backup when the dev -> prod transition from your example occurs.

I've never tried such backups, moreover they apply to file state only.

I agree that adding these pesky ifs grains['dev'] is ugly, but I see couple of other options how you can handle this:

  1. Use rector system, detect e.g. via separate state minion transitions (dev->prod) and propagate custom event when such occurs. Handle this event appropriately (given list of executed states create states that will revert some minion changes)
  2. Maybe it is feasible (on such transition) to trash the whole minion and provision him from the scratch. After all you have automated configuration management - why not to leverage this functionality and discard minions (optionally backing up data)
  3. Write custom states, that wrap original states but store the initial minion state and offer rollback (e.g. for pkg you could list initial packages installed on OS and during rollback purge all others). Unfortunately I don't think this is easy or even possible

<crazy>
If the minion uses file system that offers snapshots (like btrfs) you can try restoring snapshots to some initial/different state upon transition events
</crazy>

If I were you I would go for the 1)

Upvotes: 1

Related Questions