22.27.129. salt.states.zk_concurrency

22.27.129.1. Control concurrency of steps within state execution using zookeeper

This module allows you to "wrap" a state's execution with concurrency control. This is useful to protect against all hosts executing highstate simultaneously if your services don't all HUP restart. The common way of protecting against this is to run in batch mode, but that doesn't protect from another person running the same batch command (and thereby having 2x the number of nodes deploying at once).

This module will bock while acquiring a slot, meaning that however the command gets called it will coordinate with zookeeper to ensure that no more than max_concurrency steps are executing with a single path.

acquire_lock:
  zk_concurrency.lock:
    - zk_hosts: 'zookeeper:2181'
    - path: /trafficserver
    - max_concurrency: 4
    - prereq:
        - service: trafficserver

trafficserver:
  service.running:
    - watch:
      - file: /etc/trafficserver/records.config

/etc/trafficserver/records.config:
  file.managed:
    - source: salt://records.config

release_lock:
  zk_concurrency.unlock:
    - path: /trafficserver
    - require:
        - service: trafficserver

This example would allow the file state to change, but would limit the concurrency of the trafficserver service restart to 4.

salt.states.zk_concurrency.lock(zk_hosts, path, max_concurrency, timeout=None, ephemeral_lease=False)

Block state execution until you are able to get the lock (or hit the timeout)

salt.states.zk_concurrency.unlock(path)

Remove lease from semaphore

Docs for previous releases are available on salt.rtfd.org.

Latest Salt release: 2014.1.13

Try the shiny new release candidate of Salt, v2014.7.0rc6! More info here.

Table Of Contents

Previous topic

22.27.128. salt.states.zcbuildout

Next topic

22.28. Execution Modules

SaltStack News

Upcoming SaltStack events, webinars and local meet ups and user groups.