-
Story
-
Resolution: Obsolete
-
Undefined
-
None
-
None
Based on discussion in the Bug Triage on May 19:
[1] We would be supporting both `apiVersion` and `group` and `version` fields for now.
Are dependencies identified?
No dependencies.
Are blockers noted?
No blockers.
What is the expected delivery timeline?
GA
Is design implementable?
- Update the `Ref` struct -> https://github.com/redhat-developer/service-binding-operator/blob/master/api/v1alpha1/servicebinding_types.go#L130 to combine `group` and `version` into a single `apiVersion` field. `group` and `version` will remain for some time in order to avoid breaking existing consumers.
- possibly apply a schema to `apiVersion` content, fail early as possible in case of incorrect values.
What is the acceptance criteria?
- Add acceptance tests demonstrating usage of the new field.
Scenario: Service selection through `apiVersion` field
Given Generic test application "gen-app-a-s-b" is running
* CustomResourceDefinition backends.stable.example.com is available
And The Custom Resource is present
"""
apiVersion: stable.example.com/v1
kind: Backend
metadata:
name: service-a-s-b
annotations:
service.binding: path={.status.data.dbCredentials},objectType=Secret,elementType=map
spec:
type: "mysql"
"""
When Service Binding is applied
"""
apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
name: service-binding-a-s-b
spec:
services:
- apiVersion: stable.example.com/v1
kind: Backend
name: service-a-s-b
application:
name: gen-app-a-s-b
apiVersion: apps/v1
resource: deployments
"""
Then Service Binding "service-binding-a-s-b" is ready
And The application env var "type" has value "mysql"
2. Docs and examples should be updated.
Is the story estimated?
3
- incorporates
-
APPSVC-871 Update Application Field Spec
-
- Closed
-