Custom environment variables for service binding

[matthewpwilson]

Feature Request

Is your feature request related to a problem?

I want to use service binding to consume a RESTful service exposed by another microservice that's part of my application. The consuming service is written using MicroProfile REST client, which has a specific naming convention for environment variables. So I want to map the attributes of the service I consume to an environment variable with a specific name. Today I can work around it like this:

apiVersion: appsody.dev/v1beta1
kind: AppsodyApplication
metadata:
  name: coffeeshop-ui
spec:
  service:
    consumes:
      - category: openapi
        name: barista-http
        namespace: default 
  env: 
    - name: EXAMPLE_BARISTASERVICE_MP_REST_URL
      valueFrom:
        secretKeyRef:
          key: url
          name: coffeeshop-barista-http

i.e. by manually referencing the secret created by the operator. However, this is relying on the details of the how the secret is created, and requires extra configuration.
It's likely that other frameworks could have similar requirements for naming of environment variables.

Describe the solution you'd like

It would be much more convenient if I could map the environment variable as part of consuming the service, perhaps something like this:

consumes:
      - category: openapi
        name: barista-http
        namespace: default 
        customEnvVar:
          name: EXAMPLE_BARISTASERVICE_MP_REST_URL
          valueFrom: url

This is somewhat similar to customEnvVar feature in the ServiceBindingRequest CRD.

[arthurdm]

thanks @matthewpwilson - this is a nice feature that allows for existing applications to get plugged in.

My only comment would be to call it something other than customEnvVar, since it could be applicable to either env var or the mount filename - depending if the user has chosen to get this information inject as env vars vs mounting.

[arthurdm]

Some additional thoughts:

• this should be consistent with the updates being made to the SBO in terms of using the name dataMappings and having these mappings outside of the services array so that you can create composed mappings
• each service should have an ID so we can reference in the mappings