scothis
commented
2 years ago This dovetails nicely with #170. In essence, the state of the cluster that lead the implementation to take a course of action is no longer true. An implementation should undo its previous action and redo that action based on the current state.
For an implementation, this means it generally should track enough information about the current state when creating a binding that it is able to remove that binding. How an implementation does this is obviously an implementation detail.
I generally don't expect the ClusterResourceMapping resource to change frequently. Defining a new mapping, or adding a version to a mapping are going to be the most common mutations.
If I’ve created service bindings against a workload resource mapping, and then I add or change a workload resource mapping to that same resource type, what should a compliant operator do? Do we need to reprocess our bindings? Do we leave them be? The spec leaves this behavior undefined.
There are a few things we can do as the API currently reads, namely recreate/reprocess existing bindings or leaving them be.
Recreating existing service bindings
What happens if we rebind our existing service bindings? If we do this, everyone is immediately informed of new/changed mappings; since workload resource mappings are effectively a shared mutable state, this is probably the least surprising behavior. However, this forces all service bindings against a particular workload type to always use the same mapping. I can imagine a use case that this falls short for: a cluster administrator needs to have a different resource mapping for different circumstances (for instance, they only want to bind
initContainerswith some service bindings, and they only wantcontainerswith some other service bindings).Leave existing bindings as they are
On the other hand, what if we leave existing service bindings alone? If a user explicitly wants to have a service binding with a workload resource mapping, and then later change the mapping to support those resources in a different manner (i.e. to support a different set of containers, see “Multiple volume entries” below), then this interpretation allows for this use case to function. However, since only one workload resource mapping may exist for a resource at any given time, users may expect that if a mapping definition is changed, then service bindings that would be affected by this change should be reprocessed. Furthermore, if we alter a workload resource mapping, we will end up in the case where the mapping that kubernetes says we are using is different from the mapping that some service bindings are actually operating under.