Repository navigation
Mutating immutable resources #12
Description
Activity
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.
Content should be included in an Implementors Guide.
From the spec:
How then should we treat immutable resources, such as
Jobs? Similarly, how do we treat containers withrestartPolicy: Never, where mutating the resource won’t change the underlyingPod? Explicitly stating that mutation occurs might limit our functionality, since wording this effectively prevents us from supportingJobsand other immutable resources.