Bug 1383724 - Use internal VIP for identity_uri and friends
Summary: Use internal VIP for identity_uri and friends
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 8.0 (Liberty)
Hardware: x86_64
OS: Linux
Target Milestone: Upstream M2
: 12.0 (Pike)
Assignee: Nathan Kinder
QA Contact: Arik Chernetsky
: 1294775 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2016-10-11 15:12 UTC by David Juran
Modified: 2020-04-15 14:43 UTC (History)
12 users (show)

Fixed In Version: openstack-tripleo-heat-templates-7.0.0-0.20170616123155.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-12-13 20:46:56 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
OpenStack gerrit 432419 0 None None None 2017-02-14 15:58:19 UTC
Red Hat Product Errata RHEA-2017:3462 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 12.0 Enhancement Advisory 2018-02-16 01:43:25 UTC

Description David Juran 2016-10-11 15:12:24 UTC
Description of problem:
The way the tripleo heat templates currently deploy deploy OpenStack, the identity_uri and similar settings (such as auth_url in netron.conf) get set to the same value as what the keystone admin endpoint is created from. By default on the VIP on the ctlplane

This is problematic, since the ctlplane primarily is a provisioning network. So if the keystone admin-endpoint reside on this network (human) openstack admins need to have access to this network from their workstations. Not ideal if it's an isolated provisioning network.

If on the other hand, the KeystoneAdminApiNetwork is changed in the ServiceNetMap to point to e.g. the network the public API:s reside on, to make access for human admins easier, then all compute nodes etc, need to have access to this network. This because the same value will be set in {netron,nova,etc}.conf. Which is not ideal either.

I would therefore propose that we set the configurations in nova.conf, neutron.conf, etc. to point to the VIP on the _internal_ network. This is after all internal communication. And then of course, we also need to make ha-proxy listen for the keystone admin port on the internal network as well. 
This way, the keystone admin endpoint can be configured independently to whatever is most suitable for the operators.

Comment 2 Juan Antonio Osorio 2017-02-10 20:59:38 UTC
so, the keystone admin endpoint's network is already configurable via the ServiceNetMap parameter in t-h-t. The default is the ctlplane network but this can easily be changed to the internal_api network if the deployer needs this.

We could, however, change the service's configuration to attemt to use the internal keystone endpoint instead of the admin though. this should be easier with services moving to keystone v3.

Comment 3 Rob Crittenden 2017-02-14 15:56:11 UTC
*** Bug 1294775 has been marked as a duplicate of this bug. ***

Comment 7 Udi Kalifon 2017-06-21 15:52:33 UTC
Sorry for comment #6, I didn't see the bug was ON_QA. Verified in OSP11.

Comment 10 errata-xmlrpc 2017-12-13 20:46:56 UTC
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.


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