Show router canonical hostname on route page

[spadgett]

If the route has a custom hostname and the router has a canonical hostname configured, show a message on the route page about setting up the DNS CNAME record.

Fixes #336
See openshift/origin#12195

cc @knobunc

[spadgett]

@juanvallejo fyi

[jwforres]

hmm... I'm not sure i want this message there all the time, I care about it at the point where I need to go set up my CNAME, or if I'm seeing my hostname isn't resolving and I'm not sure why

@ajacobs21e @lizsurette any thoughts?

[ajacobs21e]

@jwforres Given that I do not understand what this message is telling the user... I agree that showing it at a time when the user can act on the message or to explain an error makes sense. Is this message something that otherwise the user would not care about or would not be able to act on? Is it implying that the user reading it is not also the DNS admin or that whatever setting needs to be changed cannot be done through OpenShift?

[jwforres]

The setting is not done in openshift, it is with the DNS provider that is providing your custom hostname. Unfortunately we have no idea whether they need the help. I was thinking maybe a help link that said something like "Need to set up a CNAME record for your hostname?" But that is pretty wordy still :-/

…

On Jan 30, 2017 11:37 PM, "Allie Jacobs" ***@***.***> wrote: @jwforres <https://github.com/jwforres> Given that I do not understand what this message is telling the user... I agree that showing it at a time when the user can act on the message or to explain an error makes sense. Is this message something that otherwise the user would not care about or would not be able to act on? Is it implying that the user reading it is not also the DNS admin or that whatever setting needs to be changed cannot be done through OpenShift? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1194 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABZk7fkkcQVyJp_RBwdr9kZELq8m1YzJks5rXrqkgaJpZM4Lx1d_> .

[spadgett]

@ajacobs21e You're telling your domain name provider that my-hostname.com is an alias to the OpenShift router (called a CNAME). It's a one-time setup outside of OpenShift.

@jwforres How about a "Don't show me again" link?

The other idea I had is to just have a "Router Hostname" field in the list with a tooltip explaining how to use it.

[ajacobs21e]

@spadgett is it possible that the user would actively decide to not set up a CNAME?

Showing it as an info alert that's dismissible is an option too

[spadgett]

is it possible that the user would actively decide to not set up a CNAME?

Not if they want their route to work :/

[spadgett]

Note that this only applies to routes with custom hostnames, but we only show the message for those.

[spadgett]

Here's the alert style:

Or positioned above:

[spadgett]

Another option:

[lizsurette]

@spadgett @jwforres @ajacobs21e I think the informational box treatment works best and I agree it would be nice to have a way to clear this message. How about just "Dismiss" as the text?

[knobunc]

@lizsurette "Dismiss" and "Don't Show Again" feel different to me. Dismiss feels temporary whereas "Don't Show Me Again" feels permanent (is there any way to get the information back once I've clicked that?)

@spadgett Something else to consider is that a single route can be admitted by two routers, each of which can have a canonical name set... Will you show the same box under each router that admitted the route?

[spadgett]

@knobunc Yeah it will loop through and show each

[ajacobs21e]

I prefer the first option with the message under the route name.

If this is a setting the user will want / need to do in order for the route to work, should the message be able to be permanently dismissed? What's the use case for not fixing this? Because there might be a lag between asking the DNS provider to change this setting and it taking effect?

[spadgett]

@ajacobs21e We have no way to know if it's been done on the OpenShift side, so we have to always show the message unless the user can dismiss it.

[ajacobs21e]

@spadgett ah makes sense. thanks for explaining. so the user could have already done all the CNAME setting stuff and still see this message.

@lizsurette do you think the action on the alert should be more "yes I understand" or "don't show again" ? I'm trying to think of something more succinct than "Don't show message again" but more permanent sounding than "dismiss"

• remove message
• hide message
• accept warning / message

[spadgett]

so the user could have already done all the CNAME setting stuff and still see this message.

yes, exactly

[lizsurette]

@knobunc Great point about dismiss. @ajacobs21e @spadgett maybe a mixture of something like "I understand, don't show again" It's a little long, but I'm thinking we can remove the "this message" since it's bounded by the box and very clear what it's referring to. Thoughts?

[spadgett]

OK, updated to this. Using the "Don't Show Me Again" text for now since it's what we say in other, similar alerts. Open to a better label.

@jwforres PTAL

[spadgett]

is there any way to get the information back once I've clicked that?

@knobunc opened #1201 to let you reset hidden alerts

[jwforres]

[merge]

[openshift-bot]

Evaluated for origin web console merge up to dd575bd

[openshift-bot]

Origin Web Console Merge Results: SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin_web_console/995/) (Base Commit: 46c6d8b)

[Download]

@spadgett @ajacobs21e @lizsurette @knobunc

As an Openshift Online Pro user trying to set up a CNAME I'd like to chime in on this...

First of all, the message need not be dismissable. The piece of information it provides is vital. I'd go a step further and say it's maybe the most important piece of information on the entire page. Without it, setting up a CNAME is not possible, which means I won't be able to connect the host name to Openshift, which means my users will not be able to reach my application.

Second of all, in my humble opinion, the internal name, router.example.com in this example, should be a property of all routes that have a custom host name set. To be shown everywhere you show other info about the route. This is critical information.

Third, there really should be documentation about setting up a custom host name. There is none at the moment that I can find. Red Hat is aware of the importance of setting up a custom host name, which is why it's one of the features listed in the Plan Comparison tables here:
https://www.openshift.com/pricing
One but last entry in the Pro Plan table shows Supports Custom Domains. However, without knowing the Openshift internal domain name I should point my CNAME to, I am unable to complete the last step.

Last... This issue was closed on januari 31st, but I am not seeing this message on Openshift Online v3. I have an app deployed on v2 that I'm trying to migrate before the EOL but this issue is preventing me from doing so and it looks like my app will now suffer downtime because of this. I started late, I admit, but I reserved thursday, friday and the weekend as spillover for what I thought would be a simple migration...

Here is what I'm seeing in the Openshift Online v3 Pro Web Console when I inspect my route:

In my humble opinion, this issue should be reopened to:

• Make sure the internal Openshift host name is always shown for these routes
• Make sure there is a specific documentation page about setting up custom host names
• Make sure that the Route screen links to those docs.