Bug 1383724

Summary: Use internal VIP for identity_uri and friends
Product: Red Hat OpenStack Reporter: David Juran <djuran>
Component: openstack-tripleo-heat-templatesAssignee: Nathan Kinder <nkinder>
Status: CLOSED ERRATA QA Contact: Arik Chernetsky <achernet>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0 (Liberty)CC: josorior, mburns, mcornea, nchandek, nkinder, nkrishna, panbalag, rcritten, rhel-osp-director-maint, sputhenp, tvignaud, ukalifon
Target Milestone: Upstream M2Keywords: Triaged
Target Release: 12.0 (Pike)   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: openstack-tripleo-heat-templates-7.0.0-0.20170616123155.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-13 20:46:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.

https://access.redhat.com/errata/RHEA-2017:3462