customEnvVar templates getting incorrectly resolved to "<no value>"

[navidsh]

I installed Service Binding Operator v0.1.0-249 from OperatorHub with the default configuration (watching all namespaces). I tried the examples/nodejs_postgresql example and added two env under customEnvVar.

apiVersion: apps.openshift.io/v1alpha1
kind: ServiceBindingRequest
metadata:
  name: binding-request
  namespace: service-binding-demo
spec:
  applicationSelector:
    group: apps
    resource: deployments
    resourceRef: nodejs-rest-http-crud
    version: v1
  backingServiceSelector:
    group: postgresql.baiju.dev
    kind: Database
    resourceRef: db-demo
    version: v1alpha1
  customEnvVar:
    - name: MY_DB_NAME
      value: '{{ .spec.dbName }}'
    - name: MY_DB_IP
      value: '{{ .status.dbConnectionIP }}'

A secret got created and has the custom environment variables but with <no value> instead of actual values from my backing service CR:

data:
...
  MY_DB_IP: <no value>
  MY_DB_NAME: <no value>

I also tried on running the operator locally based on master@24a8d0e, and see the same behavior. This used to work on v0.0.24-214.

[sbose78]

Ouch, let me check cc @Avni-Sharma @isutton

[isutton]

Hi,

First, thanks for reporting this, it's very much appreciated :)

Recently we introduced the ability of binding multiple services with an application, and might have not covered this case after the change.

We'll work to solve that shortly.

[sbose78]

This is being actively worked upon. As part of the effort, we'll slightly change how a user specifies the customEnvVar template, to bring into consideration multiple backing services

https://issues.redhat.com/browse/APPSVC-478

Bug Description
On adding multiple backing services, we've end up causing a issue for customEnvVar. Therefore, we need to update the approach to collect data, and allow users to find all data regardless of how many backends are informed.

Solution
Currently the expressions are having the .spec., or .status., and therefore it needs to support multiple backing services. To add support, the expressions need to take Kubernetes Resource Kind and resourceRef in consideration, like the following:

{{ ...spec. }}
{{ ...status. }}
And therefore, we can employ use cases like issue-352.

Documentation and Examples
Make sure all documentation and examples using customEnvVar are updated.

[isutton]

#360 reverts a mistake introduced recently, where CustomEnvParser was being fed with a map containing produced environment variables instead of a map with all visited paths from a service.

Bear in mind it currently uses one map for all visited paths from multiple services, so .status.dbName could have an unexpected value if all services share the same key.

[sbose78]

Should be good, given that we are yet to adopt multiple services widely.

[sbose78]

@pdettori @navidshaikh @arthurdm

We've put in a fix. By any chance would you be able to validate master against your use case?

I would have @DhritiShikhar roll out the release to operatorhub then to unblock folks. We are then going to support multiple services properly in customEnvVar, in a separate PR.

#360

[pdettori]

@sbose78 just tested, works for me with original syntax, even if I had to do some workaround for #358

[navidsh]

@sbose78 I also just tested and everything seems to be working fine. Thanks guys!