You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the first pass of the dynamic caching layer for ClusterExtension-managed content, we focused on core functionality and left optimizations for the future. This meant that the fastest path to core functionality being implemented was to stop and remove the old controller-runtime cache and create a new one on every call of the Watch() method for a given ClusterExtension.
Identified as an area of improvement, this ticket is meant to track the work necessary to optimize the caching layer by re-using the controller-runtime cache created on an initial Watch() method call.
This work likely involves:
Updating the existing logic to check if a cache has been created for a provided ClusterExtension
IF a cache HAS NOT been created for the provided ClusterExtension
Build a new runtime.Scheme with the provided client.Object slice
Store the runtime.Scheme for future modification
Keep a set of client.Objects used to create informers
IF a cache HAS been created for the provided ClusterExtension
Get the set of NEW resources that need to be managed
Using the set of NEW resources, update the runtime.Scheme for the ClusterExtension to register the new resources
Establish new watches/informers for the NEW resources to be managed
Get the set of resources that no longer need to be managed
Use the RemoveInformer() method on the cache.Cache type to remove the informers for no longer managed resources
Update the set of stored client.Objects to the new set of managed resources
Acceptance Criteria
Dynamic caching layer for ClusterExtension managed content is updated to re-use controller-runtime caches as outlined above
Unit tests updated as necessary
The text was updated successfully, but these errors were encountered:
In the first pass of the dynamic caching layer for ClusterExtension-managed content, we focused on core functionality and left optimizations for the future. This meant that the fastest path to core functionality being implemented was to stop and remove the old controller-runtime cache and create a new one on every call of the Watch() method for a given ClusterExtension.
Identified as an area of improvement, this ticket is meant to track the work necessary to optimize the caching layer by re-using the controller-runtime cache created on an initial Watch() method call.
This work likely involves:
Acceptance Criteria
The text was updated successfully, but these errors were encountered: