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
We have a lot of functionality that is already done in the controllerutil package of controller-runtime. We can leverage this to remove
the complexity of writing our own and reduce cognitive load around functionality that already exists.
Since upgrading controller-runtime we can also use interceptors in our unit tests which act like a prependReactor from client-go to assert on the failures of certain client calls.
Additional Context
This will help provide a means to help maintainability around the operator going forward.
Risks/Concerns
Benefits include utilizing a lib that already does what we need to replace the shared logic we are trying to consume and decouple the things we have rolled out to better create the operator going forward.
What other approaches were considered?
If we don't do it, we suffer the implementation that was used from over a year ago to maintain what could be utilized with a lib we already import.
Implementation details
Swapping out functions, deleting old code and updating the use cases we wish to implement.
Checklist
This proposal has remained open for at least one week, to allow time for community feedback.
The text was updated successfully, but these errors were encountered:
We have a lot of functions that do what this package does such as
remove<name of thing>Finalizer which actually uses the package in question. If we want to standardize around this to not have as many functions which do the same thing, we can optimize here.
What design is being proposed?
We have a lot of functionality that is already done in the
controllerutil
package of controller-runtime. We can leverage this to removethe complexity of writing our own and reduce cognitive load around functionality that already exists.
Since upgrading controller-runtime we can also use interceptors in our unit tests which act like a
prependReactor
from client-go to assert on the failures of certain client calls.Additional Context
This will help provide a means to help maintainability around the operator going forward.
Risks/Concerns
Benefits include utilizing a lib that already does what we need to replace the shared logic we are trying to consume and decouple the things we have rolled out to better create the operator going forward.
What other approaches were considered?
If we don't do it, we suffer the implementation that was used from over a year ago to maintain what could be utilized with a lib we already import.
Implementation details
Swapping out functions, deleting old code and updating the use cases we wish to implement.
Checklist
The text was updated successfully, but these errors were encountered: