anchor.diff:  ----
   
   This naive Ansible playbook will stop all Elasticsearch nodes at the same time, 
  -making the whole cluster unavailable until nodes are started again.
  +making the whole cluster unavailable until enough nodes are started again.
   To fix this problem, the role can be ran in serial instead of parallel:
   
   .deploy.yml
  
positive.code: ----
  
  But deploying every host, one after the other (in serial), takes a very long time and makes deployment endless.
  
  == Refactoring the role
  
  
negative.code: Ansible is a nice tool to deploy distributed systems like Elasticsearch, Kafka, Cassandra and the like.
  These systems are built with high availability in mind and can tolerate partial failures.
  However, upgrading these softwares, or updating their configuration, requires restarting each member of the cluster.
  Care must be taken when deploying changes to avoid complete unavailability.
  
  The aim of this article is to describe a pattern I discovered
  trying to improve the deployment speed of Ansible playbooks
  and yet being able to guarantee availability during this upgrade process.
  This is the story of two contradicting goals.
  To improve deployment speed, you need to deploy all hosts in parallel.
  To guarantee availability, you can't stop all hosts at the same time: you must deploy each host one after the other.
  
  == The problem
  
  Let's take the Elasticsearch example to explain Ansible basics.
  
  The tasks required to deploy Elasticsearch on each host of the cluster are gathered in an `elasticsearch` role.
  In short, the `elasticsearch` role is the recipe to install and update an Elasticsearch on a given machine.
  Once declared, this role is applied to all hosts belonging to the `elasticsearch` group in the Ansible playbook.
  
  .playbook.yml
  