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

Bug 2034512

Summary: Clarify IdMServer, IdMDomain can be removed when IDM servers are clustered with replication
Product: Red Hat OpenStack Reporter: Donghwi Cha <dcha>
Component: documentationAssignee: RHOS Documentation Team <rhos-docs>
Status: CLOSED NOTABUG QA Contact: RHOS Documentation Team <rhos-docs>
Severity: high Docs Contact:
Priority: high    
Version: 16.2 (Train)CC: alee, astillma, gregraka, jinjli, rheslop
Target Milestone: z3Keywords: Documentation, Triaged
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: 2023-01-27 21:37:27 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:
Bug Depends On: 2034765    
Bug Blocks:    

Description Donghwi Cha 2021-12-21 07:50:35 UTC 
Description of problem:

This is about hwo to provide IdMServer for TLSe. 

In case that there are more than two IPA servers and they are replicated as a single cluster, TLSe application needs further consideration on how to run ipa-client-install command line when registering overcloud nodes to IPA server cluster. 

Issue 
a) TLSe Document recommend to use IdMServer, IdMDomain 
b) When these parameters are provided for OSP deployment, it forces TripleO Heat engine to provide only one ipa server parameter when running ipa-client-install on the node registration during the time of initial bare metal node creation of overcloud.
c) But for ipa-client-install, providing one IPA server hostname can not guarantee fail over based on the warning message of its installation log 

-- [ IPA client Install ] -- 
>> Autodiscovery of servers for failover cannot work with this configuration.
>> If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure

d) In fact ipa-client-install should not be provided of any IPA server hostname  and must be based on DNS discovery for the successful connection failover in terms of client side LB. 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/installing_identity_management/installing-an-ipa-client-basic-scenario_installing-identity-management#installing-ipa-client-non-interactive-install_install-client-basic
..  --server to specify the FQDN of the IdM server to connect to. When this option is used, DNS autodiscovery for Kerberos is disabled and a fixed list of KDC and Admin servers is configured. Under normal circumstances, this option is not needed as the list of servers is retrieved from the primary IdM DNS domain... 

To clear the issue above,
Document needs update for the two use cases in regards of TLSe setup 
- using IdMServer, IdMDomain on TLSe application with 1 IPA host w/o any further replication 
- not using and excluding IdMServer, IdMDomain for TLSe application with 2 or more IPA host's cluster 
 

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


How reproducible:


Steps to Reproduce:
N/A 

Actual results:
N/A 

Expected results:
N/A 


Additional info:

The heat template is already mentioning it is not required and not a usual configuration as the IPA host name normally provided by DNS discovery. 

  IdMServer:
    default: ''
    description: FQDN for the FreeIPA server.  If you set this value, IdMDomain
                 also has to be provided.  Typically, this is discovered
                 through DNS and does not have to set explicitly.
    type: string
Comment 2 Donghwi Cha 2021-12-21 08:56:24 UTC 
Hi. Here is more information. 

When one of the IPA server from the two IPA replication cluster is down, 
Ansible module sometimes fails to find IPA host as seen below, 
with or without IdMServer, IdMDomain in overcloud heat template. 

2021-12-20 11:32:56,163 p=101181 u=mistral n=ansible | 2021-12-20 11:32:56.163432 |                                      |    WARNING | Module did not set no_log for random_password
2021-12-20 11:32:56,164 p=101181 u=mistral n=ansible | 2021-12-20 11:32:56.164471 | 525400ab-bd08-bd92-0123-000000001fb7 |      FATAL | add new host with random one-time password | undercloud | error={"changed": false, "msg": "host_find: Request failed: <urlopen error [Errno 113] No route to host>"}
2021-12-20 11:32:56,272 p=101181 u=mistral n=ansible | PLAY RECAP *********************************************************************
2021-12-20 11:32:56,273 p=101181 u=mistral n=ansible | exmaple-compute-1          : ok=151  changed=83   unreachable=0    failed=0    skipped=64   rescued=0    ignored=0
2021-12-20 11:32:56,273 p=101181 u=mistral n=ansible | exmaple-compute-2          : ok=147  changed=83   unreachable=0    failed=0    skipped=64   rescued=0    ignored=0
2021-12-20 11:32:56,273 p=101181 u=mistral n=ansible | exmaple-controller-1       : ok=165  changed=100  unreachable=0    failed=0    skipped=53   rescued=0    ignored=0
2021-12-20 11:32:56,273 p=101181 u=mistral n=ansible | undercloud

So it is necessary to clarify first whether removing IdMServer, IdMDomain parameter from overcloud deploy is recommended or not. 

If removing IdMServer, IdMDomain from Overcloud Heat template is verified to be fine technically first by engineering,

then the document update can follow subsequently.
Comment 11 Roger Heslop 2023-01-27 21:37:27 UTC 
Fixed in openstack-tripleo-heat-templates-11.6.1-2.20220821010130.b1e9bfe.el8ost (see https://bugzilla.redhat.com/show_bug.cgi?id=2034765 comment 13)