From 1f8d441f721adfc17a483f3b71fbb8f0fc7174d4 Mon Sep 17 00:00:00 2001 From: oddly Date: Wed, 12 Aug 2026 14:26:09 +0200 Subject: [PATCH] fix(elasticsearch): use configurable retry budget on the post-restart health wait MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The 'Wait for cluster health to return to yellow or green' step in elasticsearch-rolling-upgrade.yml was hardcoded at 30 retries × 30 seconds = 15 min, while its pre-node-down sibling reads elasticsearch_upgrade_health_retries (default 100) and elasticsearch_upgrade_health_delay (default 30). That asymmetry matters: on incus-ci debian12 the mixed-version 8→9 peer discovery routinely takes >15 min to complete under load, so the previous sibling wait sat under budget while this one timed out with the exact 'attempts: 30, number_of_nodes: 1' shape we have been chasing. Point the post-restart wait at the same two variables so operators can tune both budgets together. --- roles/elasticsearch/tasks/elasticsearch-rolling-upgrade.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/roles/elasticsearch/tasks/elasticsearch-rolling-upgrade.yml b/roles/elasticsearch/tasks/elasticsearch-rolling-upgrade.yml index 6ca8d2c3..83299a38 100644 --- a/roles/elasticsearch/tasks/elasticsearch-rolling-upgrade.yml +++ b/roles/elasticsearch/tasks/elasticsearch-rolling-upgrade.yml @@ -331,8 +331,8 @@ ((elasticsearch_response.json | default({})).status | default('')) in _elasticsearch_upgrade_health_statuses and ((elasticsearch_response.json | default({})).number_of_nodes | default(0) | int) >= _elasticsearch_upgrade_expected_nodes | int - retries: 30 - delay: 30 + retries: "{{ elasticsearch_upgrade_health_retries | int }}" + delay: "{{ elasticsearch_upgrade_health_delay | int }}" vars: # Same gate as the pre-node-down health wait so both sides of the # rolling loop honour the same operator preference.