VIPs lack colocation constraints

Bug #1810919 reported by Andrea Ieri
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Neutron API Charm
Triaged
Medium
Unassigned

Bug Description

VIPs should only be instantiated when haproxy is running. If haproxy is down, the VIP should be moved onto a unit where haproxy is functional.

This can be implemented by setting a colocation constraints, e.g.:

crm configure colocation vip_with_haproxy inf: <vip group> <haproxy clone set>

How to reproduce:
* on a unit where a VIP is held, block haproxy from running (e.g. service haproxy stop ; chmod -x /usr/sbin/haproxy

Expected result:
* the VIP group resource will be transitioned onto a different unit

Current result:
* the VIP group does not move

NOTE: colocation constraints won't work if the haproxy resource is marked as started, i.e. this bug depends on LP#1810918
NOTE: I experienced this on neutron-apis, but this bug appears to affect all principal charms

Revision history for this message
James Page (james-page) wrote :
James Page (james-page)
Changed in charm-neutron-api:
status: New → Triaged
importance: Undecided → Medium
milestone: none → 19.04
David Ames (thedac)
Changed in charm-neutron-api:
milestone: 19.04 → 19.07
David Ames (thedac)
Changed in charm-neutron-api:
milestone: 19.07 → 19.10
David Ames (thedac)
Changed in charm-neutron-api:
milestone: 19.10 → 20.01
James Page (james-page)
Changed in charm-neutron-api:
milestone: 20.01 → 20.05
David Ames (thedac)
Changed in charm-neutron-api:
milestone: 20.05 → 20.08
James Page (james-page)
Changed in charm-neutron-api:
milestone: 20.08 → none
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.