There are two tooltips on the Route page in the management console. Router Canoncal Hostname -- The documentation for UPI DNS requirements, and the IPI installer itself, do not do anything with the router canonical hostname. While the console says this hostname is "optional", it's not referred to anywhere, and likely is not configured in ANY OpenShift environment because we don't even suggest doing so: https://docs.openshift.com/container-platform/4.6/installing/installing_bare_metal/installing-bare-metal.html#installation-dns-user-infra_installing-bare-metal The only thing that is documented and guaranteed is a *.apps DNS entry, which is created by the ingress operator (in IPI) or by the user (in UPI). The second tooltip is "Do you need to set up custom DNS?" The entry reads as follows, for a sample route: --- To use a custom route, you must update your DNS provider by creating a canonical name (CNAME) record. Your CNAME record should point to your custom domain console-latest.apps.cluster-195f.195f.example.opentlc.com, to the OpenShift canonical router hostname, apps.cluster-195f.195f.example.opentlc.com, as the alias. --- Note that, as above, apps itself is not configured. The wildcard is configured. Routes are, by default, exposed as: {servicename}-{namespacename}.{cluster-base-domain} Since this {servicename}-{namespacename} paradigm is guaranteed to work because of the requirements/prereqs for a *.apps wildcard, the above text should be amended to recommend the CNAME point to the default route that would be created. Otherwise, it is extremely/highly likely that the instructions, as provided, will not work. This also applies to the dev console.
Did not get a chance to look into this. Will work on it in the next sprint
We did not have time to fix this issue this sprint. Will reevaluate and try to fix in next sprint.
Andrew, can you give us guidance on what to show here? Erik, note that we *only* show this message if a router canonical hostname is set: https://github.com/spadgett/console/blob/fc81b5feb552de8b2771d155ed9719e8a84f93c5/frontend/public/components/routes.tsx#L305
But we show that if it is set *in the cluster*, and not *in the world*. On the systems where I've seen that a `dig` of the hostname displayed doesn't actually resolve (NXDOMAIN). I don't think the installer actually sets a canonical hostname in the DNS provider with IPI. I'm checking, though.
I just validated that the router's canonical hostname DNS entry is *not* created during an AWS IPI install: --- dig apps.cluster-57b8.57b8.example.opentlc.com ; <<>> DiG 9.11.25-RedHat-9.11.25-2.fc33 <<>> apps.cluster-57b8.57b8.example.opentlc.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23587 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;apps.cluster-57b8.57b8.example.opentlc.com. IN A ;; Query time: 175 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Thu Jan 07 14:38:15 EST 2021 ;; MSG SIZE rcvd: 71 --- This is a 4.6.3 cluster. I am not seeing the "custom dns" tooltip, but clicking the "Router Canonical Hostname" words brings up: --- CanonicalHostname is the external host name for the router that can be used as a CNAME for the host requested for this route. This value is optional and may not be set in all cases. --- I'm validated that's because this particular route uses the default name for the route hostname, and does not have a "custom" route hostname. I created a route for "www.cnn.com" and then I did, in fact, see the "Do you need to set up custom DNS?" tooltip. As expected, it makes the same claim about canonical hostname: --- To use a custom route, you must update your DNS provider by creating a canonical name (CNAME) record. Your CNAME record should point to your custom domain www.cnn.com, to the OpenShift canonical router hostname, apps.cluster-57b8.57b8.example.opentlc.com, as the alias. --- There is no DNS entry for "apps.cluster...", so this would never work.
My reading of the API doc for `routerCanonicalHostname` is that it's meant exactly for this purpose. If the value is getting set automatically to a hostname that won't work, we need the Network Edge team to take a look. Andrew, if this is a console bug, let us know. We'd need guidance on what to do instead. Thanks!
*** Bug 1940545 has been marked as a duplicate of this bug. ***
PR https://github.com/openshift/cluster-ingress-operator/pull/610
Verified in "4.8.0-0.ci.test-2021-05-17-053804-ci-ln-c6w7zi2-latest". With this payload it is observed that the `routerCanonicalHostname` field in route resources gets populated with name in `router-default.<clustername>.<base-domain>` format as intended. ------ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.8.0-0.ci.test-2021-05-17-053804-ci-ln-c6w7zi2-latest True False 70m Cluster version is 4.8.0-0.ci.test-2021-05-17-053804-ci-ln-c6w7zi2-latest oc get route service-secure -o yaml apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: openshift.io/host.generated: "true" creationTimestamp: "2021-05-17T07:03:40Z" labels: name: service-secure name: service-secure namespace: test1 resourceVersion: "49866" uid: 19a3e019-8c59-41df-b25d-6e9361233ab0 spec: host: service-secure-test1.apps.ci-ln-c6w7zi2-f76d1.origin-ci-int-gce.dev.openshift.com port: targetPort: https to: kind: Service name: service-secure weight: 100 wildcardPolicy: None status: ingress: - conditions: - lastTransitionTime: "2021-05-17T07:03:40Z" status: "True" type: Admitted host: service-secure-test1.apps.ci-ln-c6w7zi2-f76d1.origin-ci-int-gce.dev.openshift.com routerCanonicalHostname: router-default.apps.ci-ln-c6w7zi2-f76d1.origin-ci-int-gce.dev.openshift.com <-- routerName: default wildcardPolicy: None - conditions: - lastTransitionTime: "2021-05-17T07:03:40Z" status: "True" type: Admitted host: service-secure-test1.apps.ci-ln-c6w7zi2-f76d1.origin-ci-int-gce.dev.openshift.com routerCanonicalHostname: router-internalapps.internalapps.ci-ln-c6w7zi2-f76d1.origin-ci-int-gce.dev.openshift.com <-- routerName: internalapps wildcardPolicy: None ------
The fix warrants a release note in case any administrators have automation that takes the canonical host name and prepends a wildcard or a subdomain. Miheer, please make sure we don't lose track of that.
The PR has been merged into 4.8.0-0.nightly-2021-06-03-014152 but robot didn't move it to verified, so moving to verified manually. also retested with 4.8.0-0.nightly-2021-06-07-023220 and the CanonicalHostname has been updated as as <ingress-controller-name>.apps.<cluster_name>.<base_domain> see: routerCanonicalHostname: router-default.apps.ci-ln-x6hpgik-f76d1.origin-ci-int-gce.dev.openshift.com
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 (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:2438