fix(elasticsearch): respect user-supplied elasticsearch_cluster_set_up#147
Conversation
The role used to overwrite elasticsearch_cluster_set_up unconditionally via set_fact based on the existence of a per-node marker file (elasticsearch_initialized_file). On a fresh node intended to join an existing multi-node cluster the marker file does not exist, so the variable was forced to false even when the user explicitly set it to true in inventory. The template then emits cluster.initial_master_nodes and the new node bootstraps its own single-node cluster instead of joining. Now the auto-detect set_fact only runs when the user has not defined the variable themselves. Existing behaviour (auto-detection on first deploy) is unchanged for users who do not set the variable. Closes #146
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe pull request modifies the elasticsearch role to respect user-supplied ChangesElasticsearch Cluster Setup Detection
🎯 2 (Simple) | ⏱️ ~8 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…cluster (#149) Two checks in the elasticsearch role assume a fresh cluster bootstrap and fail when a node is added to an existing cluster: 1. Master-count check (tasks/main.yml) requires an odd count of master nodes among `ansible_play_hosts_all`. When joining one or two new masters at a time, the limited play has 1-2 master-eligible hosts and the check fires even though the existing cluster already has its own quorum. 2. Runtime cluster setup block (tasks/elasticsearch-security.yml) tries the bootstrap password against the ES API, intending to seed elastic user, built-in user passwords, etc. On a node joining an existing cluster the elastic user already has its real password (replicated via cluster state), so bootstrap auth fails and the block aborts with: "Bootstrap password authentication failed and this is not the CA host". Both fixes gate the relevant tasks on `elasticsearch_cluster_set_up`, consistent with the pattern from #146/#147: when the user signals that the cluster is already bootstrapped, do not run bootstrap-only logic. Closes #148 Co-authored-by: Sam Crauwels <scrauwels@rinis.nl>
Summary
Fixes #146.
The
elasticsearchrole overwriteselasticsearch_cluster_set_upunconditionally viaset_factbased on a per-node marker file. When a fresh node joins an existing multi-node cluster, the marker file doesn't exist, so the variable is forced tofalseeven if the user explicitly set ittruein inventory. The template then emitscluster.initial_master_nodes, and the new node bootstraps its own single-node cluster instead of joining.This PR makes the auto-detect
set_factonly run when the user has not defined the variable themselves. Existing behaviour for users who don't set the variable is unchanged — the marker file is still consulted on first deploy.Change
Two
set_facttasks (one fortrue, one forfalse) collapsed into a single conditional task:The second
set_factlater inmain.yml(after security setup, line ~580 — referencing #137) is unchanged: that one explicitly marks the cluster as set up after this node finishes its security configuration, which is correct behaviour for both new-cluster and join-existing-cluster paths.Test plan
elasticsearch_cluster_set_up: truein inventory now correctly omitscluster.initial_master_nodesfrom the rendered config and joins the existing clusterSummary by CodeRabbit