-
Epic
-
Resolution: Won't Do
-
Undefined
-
None
-
None
-
None
-
custom variables jsonpath
-
To Do
-
QE Needed, Docs Needed, TE Needed, Customer Facing
-
0% To Do, 0% In Progress, 100% Done
Upstream
https://github.com/redhat-developer/service-binding-operator/issues/388
Goal
Custom variables help ServiceBinding users define their own binding secret fields by stitching together information from one or morer backing services using the Go templating language.
The goal of this epic is to ALSO let the users express the same thing using jsonpath which a lot of users find significantly easier to write.
Example:
apiVersion: apps.openshift.io/v1alpha1
kind: ServiceBindingRequest
metadata:
name: binding-request
namespace: service-binding-demo
spec:
applications:
- resourceRef: java-app
group: apps
version: v1
resource: deployments
services:
- group: postgresql.baiju.dev
version: v1alpha1
kind: Database
resourceRef: db-demo
dataMapping:
- name: JDBC_URL
value: 'jdbc:postgresql://{{ .status.dbConnectionIP }}:{{ .status.dbConnectionPort }}/{{ .status.dbName }}'
- name: DB_USER
value: '{{ index .status.dbConfigMap "db.username" }}'
- name: DB_PASSWORD
value: '{{ index .status.dbConfigMap "db.password" }}'
The goal of this epic is to let the users express the same thing using jsonpath which a lot of users find significantly easier to write.
Why is this important ?
- Supporting jsonpath provides users a way to express custom variables in a format which is friendlier than Go templates in a lot of scenarios.
- Some users prefer jsonpath while others prefer Go templates.
Below is a comparison on use of Go templates v/s jsonpath
customEnvVar:
- name: KAFKA_BOOTSTRAP_SERVERS
value: |-
{{- range .status.listeners -}}
{{- if and (eq .type "plain") (gt (len .addresses) 0) -}}
{{- with (index .addresses 0) -}}
{{ .host }}:{{ .port }}
{{- end -}}
{{- end -}}
{{- end -}}
Equivalent use of jsonpath
customEnvVar:
- name: KAFKA_BOOTSTRAP_SERVERS
value: {range .status.listeners[?(@.type=="plain")].addresses[0]}{@.host}:{@.port}{end}