Bug 1294775

Summary:	The keystone adminURL and internalURL are always created on the ctlplane
Product:	Red Hat OpenStack	Reporter:	Udi Kalifon <ukalifon>
Component:	openstack-tripleo-heat-templates	Assignee:	Jiri Stransky <jstransk>
Status:	CLOSED DUPLICATE	QA Contact:	Shai Revivo <srevivo>
Severity:	high	Docs Contact:
Priority:	urgent
Version:	8.0 (Liberty)	CC:	cylopez, ggillies, hbrock, hjensas, jcoufal, jslagle, kbasil, mburns, mcornea, nkinder, panbalag, rcritten, rhel-osp-director-maint, sclewis
Target Milestone:	---	Keywords:	Regression
Target Release:	10.0 (Newton)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-02-14 15:56:11 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:

Description Udi Kalifon 2015-12-30 09:34:31 UTC

Description of problem:
In my ServiceNetMap I specify "KeystoneAdminApiNetwork: internal_api", but then when I run "keystone catalog" on the deployed overcloud - I see the adminURL and internalURL on the ctlplane (172.16.x.x in my case, while all other services that are mapped to internal-api are correctly on 10.35.191.x)


Version-Release number of selected component (if applicable):
openstack-tripleo-heat-templates-0.8.7-2.el7ost.noarch


How reproducible:
100%


Steps to Reproduce:
1. Deploy an overcloud with network isolation, and put the KeystoneAdminApiNetwork on the internal_api network
2. Run "keystonre catalog" on the overcloud once it's deployed


Actual results:
The keystone adminURL and internalURL are always created on the ctlplane


Expected results:
The end[points should be on the network they were mapped to


Additional info:
In 7.2 this bug was fixed, but in 8.0 it is happening again.

Comment 3 Mike Burns 2016-04-07 21:03:37 UTC

This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.

Comment 6 Rob Crittenden 2017-02-14 15:56:11 UTC


*** This bug has been marked as a duplicate of bug 1383724 ***