With this update, Red Hat OpenStack Platform contains a new parameter `DnsSearchDomains`. You can use this parameter for IDM and FreeIPA environments that have different DNS subdomains. Set this parameter in the `parameter_defaults` section of an environment file to add a list of DNS search domains to `resolv.conf`.
I performed the following test in our environment. This test was done on OSP 13.
1. Created an IDM server with the following invocation:
ipa-server-install -U -r OOODOMAIN.EXAMPLE.COM -n oootest.example.com -p redhat123 -a redhat123 --hostname `hostname -f` --ip-address 10.12.6.77 --setup-dns --auto-forwarders --auto-reverse
Note that the domain was set to oootest.example.com which is entirely different from the realm OOODOMAIN.EXAMPLE.COM.
The hostname of my IPA server was set to ipa-server.oootest.example.com.
2. Created a "vanilla" undercloud that is not registered with the IdM server.
3. In my tests, I found that when the domain does not match the realm, the ipa-client-install
command fails because logic in krb5 to discover the KDCs fails. The workaround for this is
simply to pass the --force option to the ipa-client-install command line.
On this undercloud, we can do this by providing extra hieradata to the ipaclient puppet module.
In undercloud.conf, the is a directive :
hieradata_override = ./hieradata-overrides-classic-undercloud.yaml
which points to a file which contains hieradata overrides. In that file, add:
ipaclient::force: true
4. Then, re-deploy the undercloud following the instructions at :
http://tripleo.org/install/advanced_deployment/ssl.html#tls-everywhere-for-the-overcloud
5. For the overcloud nodes, the same workaround needs to be applied.
This can be done by updating the cloud-init script that is executed on the overcloud nodes.
For OSP13, this script is at /etc/novajoin/cloud-config-novajoin.json
Modify that file so that the ipa-client-install command is executed with the following options:
--force --hostname $fqdn
Restart novajoin and the nova processes.
With these workarounds, it was possible to deploy the overcloud and undercloud with no issues.
I performed the following test in our environment. This test was done on OSP 13. 1. Created an IDM server with the following invocation: ipa-server-install -U -r OOODOMAIN.EXAMPLE.COM -n oootest.example.com -p redhat123 -a redhat123 --hostname `hostname -f` --ip-address 10.12.6.77 --setup-dns --auto-forwarders --auto-reverse Note that the domain was set to oootest.example.com which is entirely different from the realm OOODOMAIN.EXAMPLE.COM. The hostname of my IPA server was set to ipa-server.oootest.example.com. 2. Created a "vanilla" undercloud that is not registered with the IdM server. 3. In my tests, I found that when the domain does not match the realm, the ipa-client-install command fails because logic in krb5 to discover the KDCs fails. The workaround for this is simply to pass the --force option to the ipa-client-install command line. On this undercloud, we can do this by providing extra hieradata to the ipaclient puppet module. In undercloud.conf, the is a directive : hieradata_override = ./hieradata-overrides-classic-undercloud.yaml which points to a file which contains hieradata overrides. In that file, add: ipaclient::force: true 4. Then, re-deploy the undercloud following the instructions at : http://tripleo.org/install/advanced_deployment/ssl.html#tls-everywhere-for-the-overcloud 5. For the overcloud nodes, the same workaround needs to be applied. This can be done by updating the cloud-init script that is executed on the overcloud nodes. For OSP13, this script is at /etc/novajoin/cloud-config-novajoin.json Modify that file so that the ipa-client-install command is executed with the following options: --force --hostname $fqdn Restart novajoin and the nova processes. With these workarounds, it was possible to deploy the overcloud and undercloud with no issues.