Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1673077

Summary:	[Hackfest] Unable to enable TLS Everywhere with nodes in IDM-controlled subdomain
Product:	Red Hat OpenStack	Reporter:	Andrew Austin <aaustin>
Component:	python-novajoin	Assignee:	Ade Lee <alee>
Status:	CLOSED DUPLICATE	QA Contact:	Pavan <pkesavar>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	14.0 (Rocky)	CC:	aaustin, josorior, lmarsh, rcritten, rmascena
Target Milestone:	---	Flags:	aaustin: needinfo-
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-05-17 15:38:55 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 Andrew Austin 2019-02-06 15:46:38 UTC

Description of problem:
Deploying in a multi-site IDM environment with site subdomains (dal.ipa.signal9.gg and xna.ipa.signal9.gg) fails when Director is configured to use one of the subdomains (dal.ipa.siganl9.gg) as the CloudDomain.

The created hosts in IDM are always in the overarching realm domain (ipa.signal9.gg) and certificate issuance fails when the host principal cannot be found.

Version-Release number of selected component (if applicable):
14.0-GA

Steps to reproduce:

1. Build an IDM environment that includes a subdomain (i.e. realm of idm.example.com with subdomain of rdu.idm.example.com)
2. Attempt to configure TLS everywhere with the subdomain as the base CloudDomain
3. Observe deployment failures
4. Reconfigure the cloud deployment to use the realm domain as the base CloudDomain
5. Observed that deployment completes normally

Comment 3 Ade Lee 2019-05-17 15:38:55 UTC

I think this is a duplicate of the following BZ. (https://bugzilla.redhat.com/show_bug.cgi?id=1631107) 
Please see the notes and details about this in that BZ, and reopen if this case is different.

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