no migration-threshold for the haproxy resource
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Neutron API Charm |
Triaged
|
Medium
|
Unassigned |
Bug Description
Since the metaparameter migration-threshold is left to the default of INFINITY for the haproxy resource, crm will always report all instances as running, even if the haproxy service may not be functional.
How to reproduce:
* block haproxy from running (e.g. service haproxy stop ; chmod -x /usr/sbin/haproxy
Expected result:
* res_neutron_haproxy will be in a stopped state after a few monitoring cycles
Current result:
* res_neutron_haproxy remains in started state, regardless of the value of fail-count
This bug may seem harmless, as separate monitoring should be alerting of haproxy failures, but having resources fail and be marked as stopped in pacemaker is necessary for colocation constraints, as they only apply based on whether a dependent resource is started/stopped, and not just on monitor action failures.
NOTE: I experienced this on neutron-apis, but this bug appears to affect all principal charms
Changed in charm-neutron-api: | |
status: | New → Triaged |
importance: | Undecided → Medium |
milestone: | none → 19.04 |
Changed in charm-neutron-api: | |
milestone: | 19.04 → 19.07 |
Changed in charm-neutron-api: | |
milestone: | 19.07 → 19.10 |
Changed in charm-neutron-api: | |
milestone: | 19.10 → 20.01 |
Changed in charm-neutron-api: | |
milestone: | 20.01 → 20.05 |
Changed in charm-neutron-api: | |
milestone: | 20.05 → 20.08 |
Changed in charm-neutron-api: | |
milestone: | 20.08 → none |