-
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}