-
Story
-
Resolution: Done
-
Major
-
None
-
Sprint 185, Sprint 188
When describing the values from that should be collected and made available by the Service Binding Request's intermediary secret, it is required for the developer to create distinct annotations for sibling properties; the annotations below exemplifies that:
servicebindingoperator.redhat.io/status.secretName-username: binding:env:object:secret servicebindingoperator.redhat.io/status.secretName-password: binding:env:object:secret
Similar approach also applies for values collected from the resource itself (from a Database resource, for example) but slightly different:
servicebindingoperator.redhat.io/status.connection.host: binding:env:attribute servicebindingoperator.redhat.io/status.connection.port: binding:env:attribute
This approach is fine for a couple of keys, but quickly becomes tedious and error prone when more keys should be exposed or, even worse, impossible to expose in the case arbitrary keys are present in the related secret.
To overcome this, the following annotation syntax should be valid:
servicebindingoperator.redhat.io/status.secretName: binding:env:object:secret servicebindingoperator.redhat.io/status.connection: binding:env:attribute servicebindingoperator.redhat.io/status.listeners: binding:env:attribute
Observe the status.listeners declaration above: it might be either a number, string, boolean, or an object or a slice of arbitrary values. In the case of this example, status.listeners is a []map[string]interface:
status:
listeners:
- host: 192.168.1.102
port: 8080
name: some-name
- host: 192.1689.1.103
port: 8080
name: other-name
In the case the related Secret indeed contains the data.host and data.port, and status.listeners contains the values specified above, the following environment variables should be produced:
STATUS_LISTENERS_0_HOST=192.168.1.102 STATUS_LISTENERS_0_NAME=some-name STATUS_LISTENERS_0_PORT=8080 STATUS_LISTENERS_1_HOST=192.168.1.103 STATUS_LISTENERS_1_NAME=other-name STATUS_LISTENERS_1_PORT=8080 STATUS_CONNECTION_HOST=192.168.1.101 STATUS_CONNECTION_PORT=5432 STATUS_SECRETNAME_USERNAME=admin STATUS_SECRETNAME_PASSWORD=password
In addition of those values being included in the resulting environment variables, those should also be available in the custom environment variable template context:
customEnvVar:
- name: MY_DSN
value: '{{ .status.secretName.username }}@{{ .status.connection.host }}:{{ .status.connection.port }}'
Similarly, status.listeners would be available as well (please note lastIdx does not exist in Go templates by default):
- name: ALL_LISTENERS
value: '{{ $len := (lastIdx .status.listeners) }}{{ $i, $e := range .status.listeners }}{{ $e.host }}:{{ $e.port }}{{ if lt $i $len }};{{ end }}{{ end }}'
The following environment variables should be available for the bound application:
STATUS_LISTENERS_0_HOST=192.168.1.102 STATUS_LISTENERS_0_NAME=some-name STATUS_LISTENERS_0_PORT=8080 STATUS_LISTENERS_1_HOST=192.168.1.103 STATUS_LISTENERS_1_NAME=other-name STATUS_LISTENERS_1_PORT=8080 STATUS_CONNECTION_HOST=192.168.1.101 STATUS_CONNECTION_PORT=5432 STATUS_SECRETNAME_USERNAME=admin STATUS_SECRETNAME_PASSWORD=password MY_DSN=admin@192.168.1.101:5432 ALL_LISTENERS=192.168.1.102:8080;192.168.1.103:8080
Acceptance Criteria
Upstream pull-request with following our definition of done.