-
Notifications
You must be signed in to change notification settings - Fork 433
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add proposal for binding credential schema #96
Conversation
The current spec specifies four fields that a broker can return; I believe this use case is quite different than input parameters. Exposing a schema for input parameters could be used by a client to dynamically generate a user experience in order to construct the It seems to me that all this accomplishes is a mechanism for documentation. It isn't actually a programmatic interface. Further, by moving supported values from the API spec to a generic field The whole point of this effort from CF's perspective is to allow ISVs to implement one API and offer their service across platforms, encouraging growth of the ecosystem of service brokers. That means that all platforms potentially need to support any bind response. In order to achieve that, valid bind responses should be part of the spec. As an example, if your broker's bind response included something Cloud Foundry doesn't know what to do with, then your broker is not compatible with Cloud Foundry. Maybe you are coming from a perspective that an end-user developer is consuming the bind response from the broker. In Cloud Foundry, only the credentials field is passed through to the enduser (and only under some circumstances). Cloud Foundry does specific operations based on the presence of all four fields. If Cloud Foundry can't intermediate the response, then we're not able to provide platform value-add. |
The use-cases are:
The two main issues I have with your argument are:
Finally, why would we rely on a service broker author to provide the correct documentation for what to expect from a binding when the binding can self describe in a way that is usable programmatically in visualization/configuration UIs and other forms of tooling? |
Thank you for the use cases. Very helpful.
OK, I get it now. This would allow a UI client to flesh out the marketplace metadata with documentation on credentials only (there will still need to be documentation for the service elsewhere). If credentials exist; not all services return credentials. I agree this would improve the UX in some cases but is this really a blocker to adoption of the spec? There are other ways an end-user could discover the format of bind credentials (e.g. bind then look at the creds). I agree broker API spec is not prescriptive with regard to format of credentials; the field is free-form object. In CF the field is opaque except in the buildpack community where there is a good deal of automation that depends on specific credentials fields. A broker is free to return any format for credentials they like, but the developer miss out on the benefit of this automation. So we provide guidance to brokers to use common fields where possible. I would expect the same would be true in other platforms. So for credentials, the broker response is platform agnostic. My concerns with platform-specific brokers stem from interpreting this
|
I'm still rolling this PR around in my head, but let me chime in on this:
Platform-specific brokers are an anti-goal, IMO. |
I totally agree with this and this should be an optional field for service broker creators to add value for their customers.
Definitely have no intention of proposing changes to output fields for bindings, only schematize those outputs which need it. I think it is sufficient to have a credentials section.
Perhaps having it named I think this could go two ways: either there are multiple different binding types which may have outputs, in which case it may be advantageous to have schematization for each of them in the outputs section. e.g.,
or credential bindings are the only type of binding with schematized outputs, in which case, we can move the field name back from
|
This makes sense to me:
Especially if the PR for a schema for the |
Signed-off-by: Brendan Melville <bmelville@google.com>
Service Binding outputs are a generic map of data, and must be schematized in the same way that input parameters are. This allows customers and tooling to reason about the expected output when binding to a service instance of a particular service type. Signed-off-by: Brendan Melville <bmelville@google.com>
@angarg12 This PR is for a different use case, and I believe should be independent from #74. We must remain diligent to keep the scope of each change as small as possible, as it is easier to reason about and quicker to implement. #74 is higher priority and gives us a well scoped use case to work through many questions about how to enable brokers to declare a schema for things. Once all those questions are worked through, adding support for additional use cases, like this one may be easier. |
Closing in favor of Issue #116, as this feature is still in proposal phase. |
Service Binding outputs are a generic map of data, and must be
schematized in the same way that input parameters are. This allows
customers and tooling to reason about the expected output when binding
to a service instance of a particular service type.