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 initContainers with some service bindings, and they only want containers with 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.