Represent service name as optional element of the standard

wtrocki commented 2 years ago

Problem

Currently, developers creating service binding have following "standard" fields available:

Binding name (often generated - it should typically have no meaning)
Type (type of the service to recognize service)
Provider (typically flavor of the configuration being used)

The big challenge when building production-ready applications with service binding is being able to bind multiple services to single pod (some of them can be the same type). To do that we currently using service binding name as way to "label" specific instances, but this is causing a number of issues:

Service binding name has an unwritten rule to follow somehow the name of the CR used as source for config
Service binding name is often generated string that developers need to reference in ther app

Proposal

Add new optional field (along with type, and provider) that will uniquely identify service. It could be:

service-name
service-label
label etc.

Developers who wish their services to be recognized this way can use this pattern and build tooling to reflect these values.

Challenges

Possible clashes with existing keys?

wtrocki commented 2 years ago

CC @baijum

wtrocki commented 2 years ago

This field can be also used as optional to fetch config in reference implementations:

https://github.com/k8s-service-bindings/spec/issues/174

scothis commented 2 years ago

This exists today as .spec.name, does that meet your needs?

wtrocki commented 2 years ago

Actually that will be it! I guess that is something I need to figure out with specific implementation I'm using (ServiceBindingOperator). Additionally name should be also part of the reference implementations in #174

baijum commented 2 years ago

Additionally name should be also part of the reference implementations in #174

We had some discussion about using the ServicdBinding resource name to identify the projected binding data. The conclusion was that it is not a good usage pattern. The application can discover projected binding data using the type, and provider (if necessary). Please see the user guide PR: #175

scothis commented 2 years ago

In general, resolving a dependency by type is going to be most robust. Using the name is useful to discriminate between two services of the same type.

pedjak commented 2 years ago

Actually that will be it! I guess that is something I need to figure out with specific implementation I'm using (ServiceBindingOperator). Additionally name should be also part of the reference implementations in

@wtrocki RedHat SBO supports the spec API where .spec.name field is available.

wtrocki commented 2 years ago

Would name became file in /bindings folder - something we can reference? If yes then all we need is tooling to support that

scothis commented 2 years ago

Would name became file in /bindings folder - something we can reference? If yes then all we need is tooling to support that

It's the name of the directory for the specific binding

nebhale commented 2 years ago

@wtrocki if this has satisfied your needs, would you mind closing the issue confirming that, please?

servicebinding / spec