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.

    - name: /trafficeserver
    - zk_hosts: 'zookeeper:2181'
    - max_concurrency: 4
    - prereq:
        - service: trafficserver

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

    - source: salt://records.config

    - name: /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(name, zk_hosts, identifier=None, max_concurrency=1, timeout=None, ephemeral_lease=False)

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

salt.states.zk_concurrency.min_party(name, zk_hosts, min_nodes)

Ensure that there are min_nodes in the party at name.

salt.states.zk_concurrency.unlock(name, zk_hosts=None, identifier=None, max_concurrency=1, ephemeral_lease=False)

Remove lease from semaphore.