fix(elasticsearch): scope master count to the current play's hosts#144
fix(elasticsearch): scope master count to the current play's hosts#144
Conversation
group_by accumulates globally across plays, so when the same role runs in two back-to-back plays against two distinct clusters (e.g. primary + a separate monitoring cluster) the second play sees the union of both clusters' master-eligible nodes. The assertion that asserts an odd master count then fails — 3 + 1 = 4 is even — even though each cluster on its own has an odd count. Scope the count to ansible_play_hosts_all, which is the set of hosts in the current play, so the assertion reflects the cluster being deployed rather than every cluster touched in the run. Extended the elasticsearch_roles_calculation scenario to reproduce this: a fourth host in a separate elasticsearch_mon group, converged in a second play within the same run. Without the fix the second play sees 4 masters and fails; with the fix it sees 1. Closes #143
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 27 minutes and 57 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
1 participant
Closes #143.
`group_by` accumulates into the global `groups` map across plays, so when the role runs against two separate clusters in the same `ansible-playbook` invocation (the reported case is a primary cluster plus a monitoring cluster), the second play sees every master-eligible node the run has touched — not just its own. A 3-node primary (odd, passes) followed by a 1-node monitor then trips the odd-count assertion at 4. Fix scopes the count via `ansible_play_hosts_all | intersect(...)` so each play evaluates only its own cluster.
To catch this in CI, extended `molecule/elasticsearch_roles_calculation` with a fourth host in a separate `elasticsearch_mon` group and a second play against that group. The scenario uses `elasticsearch_check_calculation: true` so it exits before installing ES — the added cost is one container, not a second cluster deploy. Without the fix, the second play sees 4 masters and fails; with the fix it sees 1 and passes.