Summary
mongodb-k8s (rev 205, channel 8-transition/edge) fails to recover after a scale-in to 0 → scale-out to 1 cycle. The single unit comes back up but stays stuck in waiting/idle with message Waiting for primary re-election... and never returns to active, timing out after 15 minutes.
Environment
- Charm: mongodb-k8s rev 205 (
8-transition/edge)
- Juju: 4.0.14
- Base: ubuntu:24.04, Kubernetes, amd64
- Test plan:
integration/glauth-k8s:ldap/ldap/mongodb-k8s:ldap
Failing test
test_scale_in_and_scale_out_charm
juju.backend.JujuWaitTimeoutError: Timed out while waiting for applications:
[active], units: [active], unit agents: [idle] (units: ['target/0'])
What happens
The test scales the mongodb-k8s application (target) down to 0 units, then back up to 1 unit, and waits for it to become active/idle.
Before scale-in — unit healthy:
Unit Workload Agent Message
target/0* active idle Primary.
After scale-out to 1 — unit stuck (never recovers within the 15 min idle timeout):
Unit Workload Agent Message
target/0* waiting idle Waiting for primary re-election...
When the sole replica-set member is removed (scale to 0) and a fresh pod is brought back (scale to 1), the charm does not complete MongoDB primary re-election, so the unit remains waiting indefinitely.
All co-deployed applications (glauth-k8s, postgresql-k8s, self-signed-certificates) stayed healthy throughout — the failure is specific to mongodb-k8s.
Steps to reproduce
- Deploy mongodb-k8s (rev 205,
8-transition/edge) with 1 unit; wait for active/idle.
juju scale-application <app> 0; wait for removal.juju scale-application <app> 1; wait for active/idle.- Unit gets stuck in
waiting — Waiting for primary re-election....
References
Filed via automated Test Observer triage.
Summary
mongodb-k8s(rev 205, channel8-transition/edge) fails to recover after a scale-in to 0 → scale-out to 1 cycle. The single unit comes back up but stays stuck inwaiting/idlewith messageWaiting for primary re-election...and never returns toactive, timing out after 15 minutes.Environment
8-transition/edge)integration/glauth-k8s:ldap/ldap/mongodb-k8s:ldapFailing test
test_scale_in_and_scale_out_charmWhat happens
The test scales the mongodb-k8s application (
target) down to 0 units, then back up to 1 unit, and waits for it to becomeactive/idle.Before scale-in — unit healthy:
After scale-out to 1 — unit stuck (never recovers within the 15 min idle timeout):
When the sole replica-set member is removed (scale to 0) and a fresh pod is brought back (scale to 1), the charm does not complete MongoDB primary re-election, so the unit remains
waitingindefinitely.All co-deployed applications (glauth-k8s, postgresql-k8s, self-signed-certificates) stayed healthy throughout — the failure is specific to mongodb-k8s.
Steps to reproduce
8-transition/edge) with 1 unit; wait foractive/idle.juju scale-application <app> 0; wait for removal.juju scale-application <app> 1; wait foractive/idle.waiting—Waiting for primary re-election....References
Filed via automated Test Observer triage.