ansible/community.general
1
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2024-09-14 20:13:21 +02:00
Code Releases Activity

Fix small doc issue | playbooks_delegation (#18494)

Browse source 
* Fix small doc issue

* Update playbooks_delegation.rst

Edited for clarity
This commit is contained in:
Alex 2016-11-16 19:44:51 +01:00 committed by scottb
parent ca5b361ad8
commit fcca6245d1
1 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
docsite/rst/playbooks_delegation.rst
View file

@ -250,20 +250,20 @@ use the default remote connection type::
Interrupt execution on any error Interrupt execution on any error
```````````````````````````````` ````````````````````````````````
With option ''any_errors_fatal'' any failure on any host in a multi-host play will be treated as fatal and Ansible will exit immediately without waiting for the other hosts. With the ''any_errors_fatal'' option, any failure on any host in a multi-host play will be treated as fatal and Ansible will exit immediately without waiting for the other hosts.
Sometimes ''serial'' execution is unsuitable - number of hosts is unpredictable (because of dynamic inventory), speed is crucial (simultaneous execution is required). But all tasks must be 100% successful to continue playbook execution. Sometimes ''serial'' execution is unsuitable; the number of hosts is unpredictable (because of dynamic inventory) and speed is crucial (simultaneous execution is required), but all tasks must be 100% successful to continue playbook execution.
For example there is a service located in many datacenters, there a some load balancers to pass traffic from users to service. There is a deploy playbook to upgrade service deb-packages. Playbook stages: For example, consider a service located in many datacenters with some load balancers to pass traffic from users to the service. There is a deploy playbook to upgrade service deb-packages. The playbook has the stages:
- disable traffic on load balancers (must be turned off simultaneously) - disable traffic on load balancers (must be turned off simultaneously)
- gracefully stop service - gracefully stop the service
- upgrade software (this step includes tests and starting service) - upgrade software (this step includes tests and starting the service)
- enable traffic on load balancers (should be turned off simultaneously) - enable traffic on the load balancers (which should be turned on simultaneously)
Service can't be stopped with "alive" load balancers, they must be disabled, all of them. So second stage can't be played if any server failed on "stage 1". The service can't be stopped with "alive" load balancers; they must be disabled first. Because of this, the second stage can't be played if any server failed in the first stage.
For datacenter "A" playbook can be written this way:: For datacenter "A", the playbook can be written this way::
--- ---
- hosts: load_balancers_dc_a - hosts: load_balancers_dc_a
@ -285,7 +285,7 @@ For datacenter "A" playbook can be written this way::
command: /usr/bin/enable-dc command: /usr/bin/enable-dc
In this example Ansible will start software upgrade on frontends only if all load balancers are successfully disabled. In this example Ansible will start the software upgrade on the front ends only if all of the load balancers are successfully disabled.
.. seealso:: .. seealso::