Bug 1231380 - VIPs should be created for each service, not each network
Summary: VIPs should be created for each service, not each network
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 7.0 (Kilo)
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: ---
: 10.0 (Newton)
Assignee: Dan Sneddon
QA Contact: Shai Revivo
URL:
Whiteboard:
: 1322989 (view as bug list)
Depends On:
Blocks: 1261979
TreeView+ depends on / blocked
 
Reported: 2015-06-12 21:41 UTC by Dan Sneddon
Modified: 2016-10-17 22:53 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-17 22:53:04 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Dan Sneddon 2015-06-12 21:41:22 UTC
Description of problem:
The new network configuration code creates isolated networks and assigns static IPs and virtual IPs for each network. Although the Pacemaker code is written to support a separate VIP for each service, we aren't currently creating the Neutron ports for each service, so all services on one network are sharing the same VIP. If a service were to fail, the IP would fail over, along with all the other services using that VIP. We need to fix that in order to achieve parity with Staypuft HA.

Version-Release number of selected component (if applicable):
  openstack-tripleo-heat-templates.noarch 0:0.8.6-7.el7ost

How reproducible:
100%

Steps to Reproduce:
1. Enable isolated networks on the latest poodle
2. Deploy
3.

Actual results:
Only one VIP is created per network, and all services are sharing it

Expected results:
The Heat templates should create a VIP for each service, and then pass that IP address to the Puppet hieradata, rather than passing a single VIP for multiple services.

Additional info:
I will be submitting a series of patches that move services to individual VIPs. The first one is https://review.openstack.org/#/c/191026

Comment 3 chris alfonso 2015-06-16 18:03:33 UTC
J, can you give us an idea of how much effort this one would take. There are a lot of HA and composable roles implications here. We are trying to figure out how invasive this is.

Comment 5 Jay Dobies 2015-06-16 18:24:32 UTC
Dan - Can you provide the effort estimate Chris is asking for?

Comment 6 Jaromir Coufal 2016-01-07 09:20:35 UTC
Dan, is this still an issue after all the work on networking? If not, please close the bug.

Comment 8 Mike Burns 2016-03-31 22:38:00 UTC
*** Bug 1322989 has been marked as a duplicate of this bug. ***

Comment 10 Dmitry Tantsur 2016-10-17 08:20:33 UTC
Hi Dan! What's the status of this bug? Was it fixed in Newton?

Comment 11 Dan Sneddon 2016-10-17 22:53:04 UTC
For a variety of reasons, including upgrade compatibility, we chose not to implement per-service VIPs. Now that we are planning for composable roles, we are revisiting the design of the VIPs. We will be breaking out the VIPs somewhat over the next several releases, but this bug is no longer valid for tracking that feature development.


Note You need to log in before you can comment on or make changes to this bug.