Multiple service resources in a `ServiceBinding` injected as a single logical service

[sbose78]

Hello folks!

May I propose that we allow the ServiceBinding resource to have multiple service objects, which would be projected into an application as a single logical service "account-database" ?

apiVersion: service.binding/v1alpha2
kind: ServiceBinding
metadata:
  name: account-database
spec:
  type: postgresdb
  name: account-database
  type: database 
  provider: 

  application:
    apiVersion: apps/v1
    kind:       Deployment
    name:       online-banking

  services:
    -  apiVersion: com.example/v1alpha1
       kind:       DatabaseInstance 
       name:     dbInstanceRef  # provides uri  
       prefix: ..

    - apiVersion: com.example/v1alpha1
       kind:       DatabaseCredentials
       name:     dbCredentials  # provides username and password
       prefix: ...

status:
  conditions:
  - type:   Ready
    status: 'True'

The injection could still happen under one logical service given that the intent of the list of services isn't to have multiple distinct logical services, rather the intent is to construct a single binding secret from multiple service objects.

$SERVICE_BINDING_ROOT
├── account-database
│   ├── type
│   ├── provider
│   ├── uri
│   ├── username
│   └── password

As already proposed in this specification, if the user wishes to add another backing service, the user may create a new ServiceBinding for a "different-service" and that would provide the following projection:

$SERVICE_BINDING_ROOT
├── account-database
│   ├── type
│   ├── provider
│   ├── uri
│   ├── username
│   └── password
├── a-different-service
│   ├── type
│   ├── provider
│   ├── uri
│   ├── username
│   └── password

The above proposal would enable one to use ServiceBinding without forcing the backing service ( or the application ?) to undergo changes.

[baijum]

This could be an extension with clarity about how the .spec.mappings works.

---

Multiple Services

Developers may require applications to connect with multiple services. This extension allows a ServiceBinding resource to specify more than one service.

If the .spec.services section is defined, it MUST be an array of services.

The .spec.mappings MAY define new entries with the name of the service as the key prefix.

Here is an example:

 mappings:
  - name:  accountServiceUri
    value: https://{{ urlquery .service1.username }}:{{ urlquery .service2.password }}@{{ .service3.host }}:{{ .prod-account-service.port }}/{{ .some-other-service.path }}

[sbose78]

Baiju, as per your proposal, would an implementor need to support both spec.service and spec.services then?

[scothis]

@sbose78 the best way to experiment with this behavior, and get the semantics right, is to create a new resource whose sole purpose is to expose a synthetic provisioned service from multiple resources. If that new resource exposes the Provisioned Service duck-type, then a ServiceBinding can consume it natively.

In general, I believe the ServiceBinding resource already does too much, and should be simpler. More advanced (and specialized) behavior can be layered on top by other resources. There's certainly a balance to strike between many focused resource and a single über binding resource.

This could be an extension...

@baijum Spec extensions cannot change the shape of the ServiceBinding resource without breaking conformance with the core spec. They can add new behavior within the schema of the current resource, but not change that schema.

[baijum]

Baiju, as per your proposal, would an implementor need to support both spec.service and spec.services then?

Yes, that was the idea.

But based on the feedback from @scothis, changing the ServiceBinding schema is not good. So, I came up with an alternate proposal that requires an additional CRD.

---

Multiservice

Developers will require applications to connect with more than one service. Creating distinct ServiceBinding resources may not be desirable for specific reasons:

1. ServiceBinding reconciler can inject all secrets at once and reduce potential conflicts
2. Application might be expecting combined secrets derived from more than one services
3. Reduce the proliferation of ServiceBinding resources
4. Less number of ServiceBinding resources might be more convenient

This extension provides a Provisioned Service called Multiservice to specify more than one service.

When the .spec.service.kind attribute is Multiservice and .spec.service.apiVersion is service.binding/v1alpha2, the ServiceBinding recociler MUST wait for Ready condition status to become True.

Resource Type Schema

apiVersion: service.binding/v1alpha2
kind: Multiservice
metadata:
  name:                 # string
  generation:           # int64, defined by the Kubernetes control plane
  ...
spec:
  services:             # []Service containing at least one entry
  - apiVersion:         # string
    kind:               # string
    name:               # string
status:
  binding:              # LocalObjectReference,
    name:               # string
  conditions:           # []Condition containing at least one entry for `Ready`
  - type:               # string
    status:             # string
    lastTransitionTime: # Time
    reason:             # string
    message:            # string
  observedGeneration:   # int64

Multiservice Example Resource

apiVersion: service.binding/v1alpha2
kind: Multiservice
metadata:
  name: combined-service
spec:
  services:
  - apiVersion: services.example.com/v1alpha1
    kind: Database
    name: database-service
  - apiVersion: services.example.com/v1alpha1
    kind: Cache
    name: cache-service
status:
  binding:
    name: combined-service-secret
  conditions:
  - type:   Ready
    status: 'True'

Service Binding with Multiservice Example

apiVersion: service.binding/v1alpha2
kind: ServiceBinding
metadata:
  name: account-service
spec:
  application:
    apiVersion: apps/v1
    kind:       Deployment
    name:       online-banking

  service:
    apiVersion: service.binding/v1alpha2
    kind:       Multiservice
    name:       combined-service

status:
  conditions:
  - type:   Ready
    status: 'True'

[arthurdm]

hey @sbose78 - I really like the scope you defined by:

The injection could still happen under one logical service given that the intent of the list of services isn't to have multiple distinct logical services, rather the intent is to construct a single binding secret from multiple service objects.

@baijum - with that in mind perhaps the name should be something like ComposedService, to avoid misuse of combining distinct services.

[baijum]

ComposedService

I changed it to Multiservice. How does that sound?

[scothis]

Is the intent of the Multiservice to bind multiple distinct services to an application at once, or to aggregate multiple service into a single projection? The OP proposal is for the later.

Assuming the former is the intent, I have a few thoughts:

• .status.binding should be removed on Multiservice since there isn't a single secret.
• what should the type, provider, env and mappings fields on the ServiceBinding do when the service is a Multiservice?
• what should a custom ServiceBindingProjection look like for a Multiservice?

If the later is the intent:

• how are values from the existing services merged?

[baijum]

ComposedService

I changed it to Multiservice. How does that sound?

After thinking some more on this and seeing the previous comment from @scothis I ComposedService makes more sense.

But I don't have a clear answer to this question he raised:

how are values from the existing services merged?

If we just join all the services' secret keys, there is a chance for name collision. Another option is to use some prefix, probably the name of the service, or introduce another attribute as @sbose78 mentioned in the description.

[navidsh]

Discussed this during interlock. There are still open questions about conflicting key/value pairs in the binding secrets.
One option is to use prefix as suggested in the issue description. Another option is to use the first index service as is and use a prefix field for the other services.

[navidsh]

Labelling as RC3 for now.

[sbose78]

Ah, missed responding to Scott. Sorry!

We could support three scenarios

1. Merging will be "deterministic" if keys are unique
2. Merging will not be "deterministic" it one or more keys are not unique. ( The user owns the risk )
3. Use of prefix. This has worked pretty well, we have users using this in the service binding operator implementation, though our API would love a lot of cleanup in this respect.

[arthurdm]

hi folks. One idea would be to include a spec.service.additionalResources element inside ServiceBinding, where it is an array of additional related resources. So for Strimzi as an example, perhaps KafkaCluster is the ref from spec.service, and KafkaUser is the [0] ref inside spec.service.additionalResources.

This way we don't need the additional CRD, and helps users understand that this is just for related CRs, not unrelated services (which should be a separate ServiceBinding CR).

[baijum]

Based on the proposal in #145, I think we can create ComposedService to compose multiple services into a single logical service.

apiVersion: mapping.service.binding/v1alpha2
kind: ComposedService
metadata:
  name: composed-service
spec:
  services:
  - apiVersion: com.example/v1alpha1
    kind:       AccountService
    name:       prod-account-service
  - apiVersion: v1
    kind:       Secret
    name:       credentials
  mappings:
  - name: username
    service: credentials
    key: username
  - name: password
    service: credentials
    key: password
  - name: host
    service: prod-account-service
    key: host
  - name: port
    service: prod-account-service
    key: port
status:
  binding:
    name: prod-account-composed-service

As you can see above, these are well-defined mappings without any ambiguity. This extension will help us during the early days where users do not want to create a Direct Secret Reference with fixed values. Once the world is full of Provisioned Service resources, probably the importance of this extension will go away!