Binding to a template with no expose annotation creates an empty secret

[spadgett]

If I create a binding against a template that doesn't use the template.openshift.io/expose annotation, I get an empty secret. It would be better to instead disable binding altogether for the service class if not supported for the template.

A lot of our template don't really make sense to bind to. For instance, sample apps like nodejs + mongo. We might consider disabling binding entirely on those to avoid confusion.

@jim-minter @ncameronbritt @sspeiche

[bparees]

I think the theory w/ making the nodejs ones bindable is that could represent a microservice you've deployed that you want to bind to.

[bparees]

(hence them exposing their URI)

[ncameronbritt]

I'm not sure it's clear to the user what creating a binding for the Node.js + MongoDB service, for example, would mean. It seems potentially confusing when a service creates more than one thing in my project.

[jim-minter]

I don't see the harm in somehow indicating that a template is not bindable, but initially I'm hesitant to link "contains no expose annotation" and "not bindable".

[bparees]

@jim-minter if it doesn't contain any expose annotations, then bind results in an empty secret, so i'm not sure what value there is in leaving it "bindable" in that case?

[jim-minter]

I'm not saying these can't be overruled, but:

• maybe someone will want to bind anyway to express that two components are grouped together in some way.
• if one day we invented a second mechanism that ran in parallel with expose, then tying expose to bindable could shoot us in the foot.
• it's not quite possible to tell statically if expose is set or not if you take parameters into account.

[bparees]

Fair enough, i think i'm reasonably convinced we should just make it an explicit decision.

[bparees]

(but we should still probably remove expose from the existing quickstart templates, and mark them not bindable once we have a way to do that).