Propagating new Binding outputs (credentials) for existing Bindings

[nilebox]

Is there any established pattern for being able to force re-fetching credentials for all existing bindings?

Example:

1. Developer releases Broker v1 creates a service TheBestDatabase with a plan Default that returns a minimal set of credentials B1 for a binding.
2. User deploys an application MyApp consuming the best database in the world.
3. Developer releases Broker v2 that adds extra fields to credentials for bindings (in a backward compatible way) for the same plan, B2 = B1 + b2.
4. The user of MyApp wants to release a new version of their app that needs those extra b2 fields. Just deploying a new app version via Deployment/Pod is not enough. Since parameters for binding haven't changed, the credentials Secret will remain havingB1. We need to force Service Catalog to issue an update request to the Broker that will fetch B2 credentials and update the credentials Secret.

---

Options:

1. Making plan versioned, i.e. Default_v1, Default_v2 etc so that user can explicitly switch instance to a new plan. But in that case there still won't be a binding update request?
2. Bumping updateRequest++ in the binding spec.

[duglin]

Is it an instance.update() or binding.get() to the broker? Those two actions could have different ACLs - so a user might be allowed to get their creds but not ask for an instance update.

W/o Get() being supported, I suspect you may have to issue a new instance.createBinding() request.

[n3wscott]

I suspect that you need to do a little work on your side of the development. I would not expect a binding to update it's binding result over time. I see a binding as pretty fixed even if Get() is supported. I would assume that the Get() on an existing binding would return the same binding result as the first time? I think the answer has to be the binding response needs to contain the version of TheBestDatabase that the credentials correspond to.

Thinking about it a bit more I think TheBestDatabase did a disservice by changing what a binding call produces, and perhaps the answer is that TheBestDatabase needs a new plan that the application needs to update to, and rebind to the new instance. Which is an interesting case of trying to answer the question of "do bindings follow service instance upgrades?" This case that answer would be no.

So a serviceInstance.planUpgradable might not be enough data to understand what happens to the bindings for that instance. I think this needs more thought for OSBAPI, it is similar to a general question we have been having around update/upgrade plans.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.