search

projectriff / riff

riff is for functions
https://projectriff.io
Apache License 2.0
799 stars 64 forks source link

RFC 0002 - Bindings #1360

Closed scothis closed 4 years ago

scothis commented 5 years ago

Please submit comments by: 2019-11-20

ojhughes commented 4 years ago

It might be useful to reference Service Catalog bindings and any similarities or differences here

scothis commented 4 years ago

@ojhughes added an FAQ item:

How do CNB Bindings relate to a Service Catalog ServiceBinding?

Service Catalog is a client to an Open Service Broker. A Service Catalog ServiceBinding is a mechanism to bind a provisioned "service" to the cluster by exposing the credentials as a Secret. CNB Bindings have no mechanism to create "service" instances, instead, its focus is binding metadata and secrets to a workload. The output of the ServiceBinding is not directly consumable by CNB Bindings. A mechanism to convert a ServiceBinding to a format consumable by CNB Bindings is out of scope for this RFC.

fbiville commented 4 years ago

If that spec were to be merged in the current state, could the implementation of service binding start?

It seems to me that the spec currently describes what bindings are but now how they are to be used. It is likely that thinking about the usage early (in that spec) would help refine binding definitions as well. What do you think @scothis?

scothis commented 4 years ago

If that spec were to be merged in the current state, could the implementation of service binding start?

@fbiville see https://github.com/projectriff/system/pull/181, which predates the RFC

fbiville commented 4 years ago

If that spec were to be merged in the current state, could the implementation of service binding start?

@fbiville see projectriff/system#181, which predates the RFC

Why start with streams and not service bindings for riff applications?

scothis commented 4 years ago

Why start with streams and not service bindings for riff applications?

@fbiville this is out of scope for the RFC, but to answer your question. The idea to start with Streams is because the problem space contains both the production of a binding (via the Stream resource) and the consumption of the binding (via the Processor resource and sources). One of the problems inhibiting bindings is that there is a network effect as more components use bindings. Creating bindings without consumers is pointless. Without producers, consuming bindings is impossible.

There's nothing to stop applications from also consuming bindings today, other than the lack of producers. The UX is meh, but it's possible. I expect to see a further RFC to refine the UX.

Again, anything related to a specific producer or consumer is out of scope for this RFC.

scothis commented 4 years ago

How could we align Crossplane's Secret propagation with this model?

With the standard caveat that the discussion is out of scope for this RFC:

The gotcha here (unless I'm mistaken) is that the secret created by Crossplane only covers the CNB Binding secret fields, and does not contain the CNB Binding metadata (kind, provider, tags, etc). The ResourceClaim has that metadata. So the trick is to coerce Crossplane into creating a ConfigMap from the ResourceClaim along side the Secret.