Bug 1496687 - Consistent binding names

[spadgett]

• Show binding name rather than secret name in collapsed overview row to be consistent with what we show when expanded.
• Remove "Secret" heading above binding name to avoid confusion. We shouldn't label a ServiceBinding as a Secret since they're different resources.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1496687

cc @ncameronbritt

[ncameronbritt]

@spadgett We should definitely address the inconsistency btw collapsed and expanded, but I want to think through which option would be more helpful for the user to see. I think the most confusing case we came up with was when you had multiple bindings and wanted to make sure you were deleting the correct one. Isn't it the secret that ends up getting tied to the application, not the binding? Can the user even do anything with the binding object? Also worth thinking about how things will be when pod presets are in.

[spadgett]

I think the most confusing case we came up with was when you had multiple bindings and wanted to make sure you were deleting the correct one.

To me, the most confusing thing is to show a list of bindings, and it's not binding names that we show, but secret names. If you run oc get servicebindings on the CLI, you'll see a totally different list.

Some users also don't have authority to view secrets, but will be able view bindings.

Can the user even do anything with the binding object?

You can check status and delete bindings. You can see what parameters were used for the binding. At some point, you might be able to update binding parameters.

If the user wants to do anything with a binding on the CLI, they'll need to know the name.

Also worth thinking about how things will be when pod presets are in.

True. Right now (in 3.6 tech preview), I believe we should the application name with the binding name in smaller, muted text.

FWIW, in the past, I've regretted it every time we've decided to pretend one thing is really another. Deployments vs replication controllers is one example. HPA target CPU is another example. We've gotten a lot of bugs like #1590 because what we show in the web console is different than the CLI. I feel like in the end it makes things more confusing and does the user a disservice.

[spadgett]

Also: you can always get to the secret from the binding, but you can't get to the binding from the secret.

[ncameronbritt]

I really thought that in 3.6 tech preview we were showing the secret or the application. I'm pretty sure that's how we designed the Provisioned Service details page too. I feel like either the binding object didn't exist when we were first working on these designs, or if it did, we just weren't aware of it.

[spadgett]

Got OK from @ncameronbritt on this after talking in person (thanks @ncameronbritt)

[merge]

[spadgett]

[merge]

[openshift-bot]

Evaluated for origin web console merge up to 425e3f9

[openshift-bot]

Origin Web Console Merge Results: SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_origin_web_console/293/) (Base Commit: a26e359) (PR Branch Commit: 425e3f9)