Mutating immutable resources

[sadlerap]

From the spec:

Values referenced by JSONPaths in both the MappingTemplate and MappingContainers MUST be mutated by a ServiceBinding reconciler as if they were defined directly by a PodTemplateSpec.

How then should we treat immutable resources, such as Jobs? Similarly, how do we treat containers with restartPolicy: Never, where mutating the resource won’t change the underlying Pod? Explicitly stating that mutation occurs might limit our functionality, since wording this effectively prevents us from supporting Jobs and other immutable resources.

[scothis]

How then should we treat immutable resources, such as Jobs?

The VMware implementation has a sample that uses a batch/v1 Job for the workload. Since Jobs becomes immutable upon creation, the easiest way to bind a service within a cluster is to intercept the request with a mutating admission webhook. The service binding controller dynamically configures the MutatingWebhookConfiguration to intercept requests to create/update the workload types.

The above is likely too much detail to put into the spec. An implementation may choose to not support immutable resources. We could say something like an implementation should act in good faith to bind a service to a workload, but may not succeed based on extant circumstances in the cluster. Non conformance should be reflected the ServiceBinding's conditions.

Similarly, how do we treat containers with restartPolicy: Never, where mutating the resource won’t change the underlying Pod?

The container restart policy is irrelevant to us. When we bind into a workload, the controller for that workload should trigger the rollout of new Pods based on its own implementation.

[nebhale]

Content should be included in an Implementors Guide.