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 "simple" 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.

Notes:

What is simple binding metadata ?

If the binding metadata being referred to is a string, then it's called "simple".

apiVersion: apps.kube.io/v1beta1
    kind: Database
    metadata:
    name: my-cluster
    spec:
    ...
    status:
        data:
            url: db.stage.ibm.com
            credentials: my-creds-secret

Here, the value of "status.data.url" & ""status.data.my-creds-secret" is a string, and thereby being referred to as "simple" metadata

What is complex binding metadata ?

If the binding metadata being referred to is a slice or slice of maps, then it's called "complex".
Associated epic: https://issues.redhat.com/browse/APPSVC-528