Problem

In order to make a service bindable, the operator provider needs to express the information needed by applications to bind with the services provided by the operator. In other words, the operator provider must express the information that is “interesting” to applications.

Without the metadata, service binding wouldn't be able to accurately detect the 'connection information' that has to be "injected" into the application.

Goal

• Support a scalable format for operator/backing service authors to decorate CRDs/CRs/CSVs/resources
• Support a format that has been validated with a fairly reasonable number of usecases.
• Validate and implement https://github.com/application-stacks/service-binding-specification/blob/master/annotations.md
• Support annotations for complex elements associated with a CR/CRD/resource that is being expressed as interesting for binding. For more details on difference between "simple" and "complex" binding metadata, refer to the "Notes" section.

Why is this important?

• Without a standard format, backing service authors wouldn't be able to accurately express what is "interesting" for applications This epic encapsulates the work needed to implement the binding metadata format as per the recently defined specification.
• A lot of backing services CRDs/CRs/resources cannot practically contain information in the "simple" format. The binding information has to be parsed from complex data structures like slices / slice of maps.

Notes:

What is simple binding metadata ?

If the binding metadata being referred to is a string, then it's called "simple".
See the Notes section of https://issues.redhat.com/browse/APPSVC-525 for more details.

What is complex binding metadata ?

If the binding metadata being referred to is a slice or slice of maps, then it's called "complex".

Example, in the following resource, if the service author wishes to

_Use specific elements from the CR’s “status.bootstrap” to produce key/value pairs in the binding Secret
_

   apiVersion: apps.kube.io/v1beta1
    kind: Database
    metadata:
    name: my-cluster
    spec:
    ...
    status:
        bootstrap:   
            - type: plain   
    	      url: myhost2.example.com
              name: hostGroup1
            - type: tls
    	      url: myhost1.example.com:9092,myhost2.example.com:9092
              name: hostGroup2
        data:
            dbConfiguration: database-config  # configmap 
            dbCredentials: database-cred-Secret # Secret
            url: db.stage.ibm.com

In the above CR, the backing service author might intend to have

• the value of status.bootstrap.type as the key
• the value of status.boostrap.url as the value in the binding secret

To be able to do so, the backing service author specifies the following annotation:

 servicebinding.dev/endpoints”:
"path={.status.bootstrap},elementType=sliceOfMaps,sourceKey=type,sourceValue=url" 

which generates a binding secret containing

endpoints.plain=myhost2.example.com
endpoints.tls = myhost1.example.com:9092,myhost2.example.com:9092

See https://github.com/application-stacks/service-binding-specification/issues/21#issuecomment-607674563 for a longer discussion.