Description of problem:
Openshift-install successfully creates cluster but the dns name of the console URL is invalid. This is a regression compared to nightlys from the previous week.
Version-Release number of the following components:
Steps to Reproduce:
1. Install cluster on Azure (used centralus region but not sure that matters)
2. try to use web console url which fails because the hostname does not resolve
[m@dhcp145-160 42_azure_install]$ ./openshift-install create cluster --dir cluster/mgahagan-092008
INFO Creating infrastructure resources...
INFO Waiting up to 30m0s for the Kubernetes API at https://api.mgahagan-092008.qe.azure.devcluster.openshift.com:6443...
INFO API v1.14.0+40a2047 up
INFO Waiting up to 30m0s for bootstrapping to complete...
INFO Destroying the bootstrap resources...
INFO Waiting up to 30m0s for the cluster at https://api.mgahagan-092008.qe.azure.devcluster.openshift.com:6443 to initialize...
INFO Waiting up to 10m0s for the openshift-console route to be created...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/m/42_azure_install/cluster/mgahagan-092008/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mgahagan-092008.qe.azure.devcluster.openshift.com
INFO Login to the console with user: kubeadmin, password: 6zHBn-tpFnS-SM3DR-GAkkH
[m@dhcp145-160 42_azure_install]$ host api.mgahagan-092008.qe.azure.devcluster.openshift.com
api.mgahagan-092008.qe.azure.devcluster.openshift.com is an alias for mgahagan-092008-9m88c.centralus.cloudapp.azure.com.
mgahagan-092008-9m88c.centralus.cloudapp.azure.com has address 22.214.171.124
[m@dhcp145-160 42_azure_install]$ host console-openshift-console.apps.mgahagan-092008.qe.azure.devcluster.openshift.com
Host console-openshift-console.apps.mgahagan-092008.qe.azure.devcluster.openshift.com not found: 3(NXDOMAIN)
cluster is functional using oc and other related tools
web console is resolvable.
*** Bug 1741957 has been marked as a duplicate of this bug. ***
cred-minter is providing ingress credentials that do have access to the public DNS zone in a separate resource group from the cluster's resource group.
*** Bug 1734167 has been marked as a duplicate of this bug. ***
Was the fix here code in cred-minter, or using a different credential?
This is kind of by-design with the new cred minter right? You can't isolate credentials and have them reach externally as well, can you?
Verified on 4.2.0-0.nightly-2019-08-22-201424
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.