Description of problem: The VIP for keystone and the GUI is on the control plane: export OS_AUTH_URL=http://192.0.2.14:5000/v2.0/ My deployment is on bare metals which are also on the 10.35.xxx.xxx network (and in addition it's a HA setup) - is there a way to have a VIP on that network without going through ssh tunnels from the undercloud? If I have to do it via the undercloud, the HA is worthless because as soon as the undercloud node goes down I'll have no way to get to the overcloud as well. Version-Release number of selected component (if applicable): openstack-tripleo-heat-templates-0.8.6-15.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. I deployed with: openstack overcloud deploy --plan-uuid 30b02f2a-6ccc-4c10-ada4-7dfb93faf3ec --control-scale 3 --neutron-public-interface eth2 --network-cidr 192.168.0.0/16 --floating-ip-start 10.35.190.10 --floating-ip-end 10.35.190.50 --floating-id-cidr 10.35.190.0/24 --bm-network-gateway 10.35.190.254 --neutron-network-type gre --neutron-tunnel-type gre
Dan, is there a patch for this upstream/downstream?
(In reply to Udi from comment #3) > Dan, is there a patch for this upstream/downstream? I'm pretty sure that this behavior is because of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1235476 There is an upstream patch to fix that, and assuming it passes CI and gets some +2 reviews it should be merged downstream.
Verified Dan's patch and the public VIP gets created on the external network: http://paste.openstack.org/show/321395/ I filed BZ#1236136 in regards to all keystone endpoints using the public VIP.
openstack-tripleo-heat-templates-0.8.6-44.el7ost.noarch keystone and horizon VIP are on external network.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2015:1549