Owner: Architect:

<Architect is responsible for completing this section to define the details of the story>

Story (Required)

As an OpenShift user, I want to have SBO perform a watch on the resources that are bound using label selectors.

Background (Required)

In APPSVC-1083, we implemented support for service bindings with label selectors picking up resources that were created after the initial service binding resolution.  This was done by periodically re-resolving every service binding with a label selector as its workload source.  This had a few drawbacks:

• SBO never gets notified of when a workload removes a label, so we never get the opportunity to deproject binding information.
  • To implement correct de-projection behavior, we would need to do a lot of extra bookkeeping (namely: keep track of all the workloads we've bound and calculate a diff when we re-resolve).  It would probably be cheaper to install a watch on these resources.
• Re-resolving these service bindings has a performance cost, especially when there are multiple service bindings that need to do so.
• It can take a while (i.e. up to 2 minutes) for a binding to re-resolve itself and pick up new resources, which may be unacceptable for some users.

Instead of this current solution, we should instead install watches on the necessary label selectors and get notified when re-resolution needs to happen.  This solves all of the above problems.

• We get notified from the watch when a workload removes its label and needs to be de-projected.
• We no longer can run into the performance problem of having to resolve a lot of service bindings, especially when we don't have to.
• We resolve service bindings when changes happen (and have leveled out), reducing the delay between label application and resolution.

Out of scope

• To keep story size contained, we shouldn't watch services. Updating bindings when the underlying service changes would be nice to have, but is out of scope for this story.
• For now, we shouldn't enable this for all workloads, just the ones with label selectors. If we want to use this for all workloads, we need to analyze the performance impact of doing so; this may not be worth it.

In Scope

• Have SBO get told when it needs to re-reconcile resources, not poll for changes.

Approach(Required)

The approach I've settled on looks like this:

• Spin up a background goroutine that calls ResourceInterface.Watch to get relevant notified of changes to relevant resources (such as the service and the workload).
• We can register a Source (more particularly, a channel) with the controller via the Watch method during setup.
• When we get notified of these changes from the Watch call, we can lookup relevant service bindings and write GenericEvents that contain the service binding that we need to re-reconcile to the channel.
• This lets us re-trigger reconciles on only the service bindings whose workloads and/or services change. Furthermore, we only need to re-reconcile service bindings that need to be re-reconciled.

Dependencies

None.

Edge Case

• It's possible to have more than one of these watches going at once.  Is it cheaper to have N goroutines, each with a single channel for watch events, or have 1 goroutine with N channels for events?  Intuition says the first, but I'm not entirely certain.
• How best to handle de-projection? The above approach does not handle it at all; further investigation is needed.

Demo

Demonstrate that re-reconciliation of label-selector resources is faster with this method.

Acceptance Criteria

• Use watches to get informed of updates to workloads
• Remove periodic rebinding logic from SBO (should now be triggered by informers)
• Needs to pass a performance evaluation (i.e. run /test performance on the PR)

INVEST Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Legend

Unknown
Verified
Unsatisfied