-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
controller code/test refactoring/additions #107
controller code/test refactoring/additions #107
Conversation
683b79e
to
3dfea44
Compare
3dfea44
to
5d27194
Compare
main bullet points are: - decrease nesting in main reconcile code by setting conditions and returning early when handling unexpected errors. - move reconciler unit tests to a separate file from the suite. if we add other controllers in the future, we'll likely want separate test files for each controller. - export the reconciler's resolver field to make it easy to swap out for tests (also add and use a test entity source) - remove the manager setup in the unit tests. this ensures we can test individual runs of the Reconcile function, which is good for two reasons: 1. no need to use `Eventually`, no polling, etc. so it speeds up the tests 2. it ensures that we fully understand the transitions that occur from a beginning state to and end state. - added more unit tests to increase code coverage. - moved conditions and reasons checks to invariants that run after every test of reconciling an existing Operator object. - make certain bundle entity properties optional. not all bundles will provide/require GVKs or require other packages. lookups for those entities should return nil slices rather than an error. - remove unnecessary RBAC rules for create/update/patch/delete Operator objects. this leaves only get, list, watch, update status, and update finalizers.
5d27194
to
bc627b6
Compare
1. factor bundle lookup into separate function, which makes for less complex main reconcile function 2. use server-side apply to ensure bundle deployment is up-to-date 3. add more unit test scenarios
I added another commit, which I think improves the controller code a bit more. It also adds more unit test scenarios. I'm fairly happy with those, but they do introduce some duplication that I think could be reduced a bit, so I think its worth a follow up to focus on that. |
if err = (&controllers.OperatorReconciler{ | ||
Client: mgr.GetClient(), | ||
Scheme: mgr.GetScheme(), | ||
Resolver: resolution.NewOperatorResolver(mgr.GetClient(), resolution.HardcodedEntitySource), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
much better!
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@@ -154,7 +154,7 @@ func (b *BundleEntity) loadRequiredGVKs() error { | |||
b.mu.Lock() | |||
defer b.mu.Unlock() | |||
if b.requiredGVKs == nil { | |||
requiredGVKs, err := loadFromEntity[[]GVKRequired](b.Entity, property.TypeGVKRequired) | |||
requiredGVKs, err := loadFromEntity[[]GVKRequired](b.Entity, property.TypeGVKRequired, false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as we discussed online, I think we should only push these booleans to constants to make it a little more readable and that's basically the cherry on top ^^
might be worth splitting the suite_test changes to a different PR. But not strictly necesssary...
I noticed y'all made some great progress this week, and got the itch to stay in the loop and pitch in. This PR is a whole bunch of changes all wrapped up together, so I have no illusions about it being merged as is. I'm curious what folks think!
Main bullet points are:
objects. this leaves only get, list, watch, update status, and update
finalizers. (reduce RBAC permissions of operator-controller #116)
Eventually
, no polling, etc. so it speeds up the testsEDIT: I split each of these main things out into separate PRs now that it seems like folks are generally onboard.