zk_concurrency¶
Control concurrency of steps within state execution using zookeeper¶
Important
This module requires the general Zookeeper setup.
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.
Example¶
This example would allow the file state to change, but would limit the concurrency of the trafficserver service restart to 4.
acquire_lock:
zk_concurrency.lock:
- name: /trafficeserver
- zk_hosts: 'zookeeper:2181'
- 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:
- name: /trafficserver
- require:
- service: trafficserver
- saltext.zookeeper.states.zk_concurrency.lock(name, zk_hosts=None, identifier=None, max_concurrency=1, timeout=None, ephemeral_lease=False, profile=None, scheme=None, username=None, password=None, default_acl=None)[source]¶
Block state execution until you are able to get the lock (or hit the timeout)