Skip to content
This repository was archived by the owner on Jun 26, 2024. It is now read-only.

Commit 67558f1

Browse files
committed
docs: document workload resource mapping
Signed-off-by: Andy Sadler <[email protected]>
1 parent 135da06 commit 67558f1

File tree

1 file changed

+87
-1
lines changed

1 file changed

+87
-1
lines changed

docs/userguide/modules/creating-service-bindings/pages/custom-path-injection.adoc

Lines changed: 87 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -79,7 +79,7 @@ spec:
7979
NOTE: This feature is only available for `ServiceBinding` in the
8080
`binding.operators.coreos.com` API group.
8181

82-
SBO provides an API to inject a binding secret name into a custom application resource field.
82+
SBO provides an API to project a binding secret name into a custom application resource field.
8383
Here is an example CR with the secret in a custom location:
8484

8585
[source,yaml]
@@ -132,3 +132,89 @@ metadata:
132132
spec:
133133
secret: binding-request-72ddc0c540ab3a290e138726940591debf14c581
134134
....
135+
136+
== Workload resource mapping
137+
138+
NOTE: Workload resource mapping is available for the secondary workloads of the ServiceBinding custom
139+
resource (CR) for both the API groups: `binding.operators.coreos.com` and `servicebinding.io`.
140+
141+
The specification also provides a way of defining exactly where binding data needs to be projected
142+
into, which may work in situations where the above methods won't work. This is done by defining
143+
`ClusterWorkloadResourceMapping.servicebindings.io` resources, which define where binding data gets
144+
projected for a given workload kind. This works for both CoreOS and specification service binding
145+
resources.
146+
147+
.Example Schema of the `ClusterWorkloadResourceMapping` resource
148+
[source,yaml]
149+
----
150+
apiVersion: servicebinding.io/v1alpha3
151+
kind: ClusterWorkloadResourceMapping
152+
metadata:
153+
name: # string <1>
154+
...
155+
spec:
156+
versions: # required, at least one entry must be defined
157+
- version: # string <2>
158+
annotations: # string (Fixed JSONPath), optional <3>
159+
containers: # optional
160+
- path: # string (JSONPath) <4>
161+
name: # string (Fixed JSONPath), optional <5>
162+
env: # string (Fixed JSONPath), optional <6>
163+
volumeMounts: # string (Fixed JSONPath), optional <7>
164+
volumes: # string (Fixed JSONPath), optional <8>
165+
----
166+
<1> Name of this resource which must be qualified as `plural.group`, such as `cronjobs.batch` for CronJobs
167+
<2> Version of the resource we're mapping. Any version not specified can be matched with the "*" wildcard.
168+
<3> Optional: where annotations live, specified with a fixed JSONPath. The default value is `.spec.template.spec.annotations`.
169+
<4> Optional: where containers live, specified with a JSONPath. If no entries are defined, the
170+
{servicebinding-title} defaults to two paths:
171+
`.spec.template.spec.containers` and `.spec.template.spec.initContainers` with all other fields
172+
set as their default).
173+
<5> Optional: Identifier of the `.name` field in a pod. The default value is `.name`.
174+
<6> Optional: Identifier of `.env` environment variables. The default value is `.env`.
175+
<7> Optional: Identifier of the volume mounts of a pod lives. The default value is `.volumeMounts`.
176+
<8> Optional: where volumes live, specified with a fixed JSONPath. The defaults value is `.spec.template.spec.volumes`.
177+
178+
[IMPORTANT]
179+
====
180+
In this context, a "Fixed JSONPath" is a subset of the JSONPath grammar that accepts only the
181+
following operations:
182+
183+
. Field lookup: `.spec.template`
184+
. Array indexing: `.spec['template']`
185+
186+
All other operations are forbidden.
187+
====
188+
189+
Most of these fields are optional, and SBO assumes PodSpec-compatible defaults when not specified.
190+
SBO requires that each of these fields is semantically equivalent to the corresponding field in a Pod
191+
deployment; failing to maintain this may result in unexpected behavior.
192+
193+
Using the above schema, one can define the following YAML as an example mapping for `CronJob.batch/v1`
194+
resources:
195+
196+
[source,yaml]
197+
----
198+
apiVersion: servicebinding.io/v1alpha3
199+
kind: ClusterWorkloadResourceMapping
200+
metadata:
201+
name: cronjobs.batch
202+
spec:
203+
versions:
204+
- version: "v1"
205+
annotations: .spec.jobTemplate.spec.template.metadata.annotations
206+
containers:
207+
- path: .spec.jobTemplate.spec.template.spec.containers[*]
208+
- path: .spec.jobTemplate.spec.template.spec.initContainers[*]
209+
volumes: .spec.jobTemplate.spec.template.spec.volumes
210+
----
211+
212+
NOTE: There is some behavior in the CoreOS API that does not exist in the specification API:
213+
214+
. If a `ServiceBinding` resource with `bindAsFiles: false` is created with one of these mappings,
215+
then environment variables will be projected into `.envFrom` underneath each `path` field specified
216+
in the corresponding `ClusterWorkloadResourceMapping` resource.
217+
. Both `ClusterWorkloadResourceMapping.servicebinding.io` resources and the
218+
`.spec.application.bindingPath.containersPath` field will be considered for binding purposes. This
219+
behavior would be equivalent to adding an entry to the corresponding `ClusterWorkloadResourceMapping`
220+
resource with `path: {containersPath}`, with all other values taking their default value.

0 commit comments

Comments
 (0)