-
Story
-
Resolution: Done
-
Major
-
None
Description
This feature aims to support operators which don't have any metadata in the CSV. The proposal here is to bind all sub-resources ( ones have "ownerReferences" ) of the backing service CR - by populating the binding secret with information from routes, services, configmaps, secrets owned by the backing service CR.
This would be triggered by an explicit API option in the CR spec called "detectBindingResources : true"
Acceptance Criteria
- Automatically detect Services, Routes and Configmaps owned by the backing service CR.
- Populate the binding secret with the information from these objects.
- The keys in the binding secret should follow the same pattern as https://kubernetes.io/docs/concepts/services-networking/service/#environment-variables .
- [mentioning the obvious] The keys in the binding secret should take into account the binding prefix
- The fields in a route that should be bound are open to discussion. For others, it is obvious.
Notes:
In case of services, this is automatically done by Kubernetes
https://kubernetes.io/docs/concepts/services-networking/service/#environment-variables
However, we will be also be explicitly doing it by honoring the binding prefix as well as by making the SBR controller react to changes in the service in order to redeploy pods.
- blocks
-
APPSVC-164 Validate service binding with a Console / UI workflow
- Closed
-
APPSVC-165 [ Spike ] ODO: Bind an imported app with an operator backed service
- Closed
- is related to
-
APPSVC-22 Document best practices for operators to ensure that they are "bind-able"
- Closed
-
APPSVC-183 Update Examples and related docs to illustrate annotation-based service binding
- Closed