-
Notifications
You must be signed in to change notification settings - Fork 468
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
Make extension components ready for cached client #4027
Conversation
/assign |
@ialidzhikov, this is the bigger refactoring I was talking about earlier. |
Strange...
Though locally, in can't get the test to fail:
|
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.
/lgtm
Well done!
pkg/operation/botanist/component/extensions/controlplane/controlplane.go
Outdated
Show resolved
Hide resolved
Thanks @rfranzke for your review, PTAL :) |
For the reasons explained in gardener#4057, MergePatchOrCreate is not safe to use without reading objects from the API server / cache first. Ideally we would switch to server-side apply to simplify such operations on controlled objects (e.g. extension resources), though we cannot leverage it for now because of several issues described in gardener#4122.
As described in gardener#4057, *PatchOrCreate is easy to use incorrectly. Remove *PatchOrCreate funcs in order to minimize the risk of misuse. There might still be good use cases for this mechanism, though they are limited. If there is such a good use case, we can use it also without a helper func.
df555de
to
9cabff7
Compare
Rebased the PR and added two more commits to make it ready again:
/unassign @rfranzke PTAL :) |
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.
/lgtm
@timebertt What about the |
Generally, the same applies to So for example, this usage needs to be adapted, as labels that were removed from the seed template won't be removed from the seed itself:
Probably, adapting the helper func to do a |
OK, thanks. For the sake of simplicity and prevention of coding bugs, I'd vote for changing the function in all cases as described above (create->get->patch) instead of (create->patch). Do you agree? |
Yes, I agree. That seems to be the more sustainable approach. |
* Cleanup unused/dead code * Make EXPECTPatch easier to debug * Refactor extensions helper funcs This prefactoring performs several changes in the extension helper funcs: - the funcs directly work on the passed in objects instead of creating new objects via separately passed newObjFuncs. Passed objects are expected to be filled with the latest state the controller/component applied/observed/retrieved, but at least namespace and name. This way, controllers can keep working on a single in-memory object instead of retrieving the same object over and over again. - WaitUntilExtensionObjectReady additionally checks that the added timestamp annotation is present on the object to prevent false early exits when reading stale data (e.g. from a cached client). - makes naming more consistent and clearer This provides the following benefits: - makes the funcs ready to be used with cached clients, as they are able to properly handle stale data now - controllers/components automatically have the latest state of the objects present without retrieving them again from the API server. This will ease further refactorings and allows to safely use patches in a lot of cases instead of CreateOrUpdate (+RetryOnConflict). - the funcs are easier to use and comprehend: only the desired object needs to be passed, no need to pass newObjFuncs, namespace and name - the funcs are more similar to other helper funcs (e.g. CreateOrUpdate) and the mechanisms employed in e.g. c-r clients - no need to pass a client.Object to postReadyFuncs which needs to be casted again * Make BackupBucket controller ready for cached client * Make BackupEntry controller/component ready for cached client * Make ContainerRuntime component ready for cached client * Make ControlPlane component ready for cached client * Make Extension component ready for cached client * Make Infrastructure component ready for cached client * Make Network component ready for cached client * Make OperatingSystemConfig component ready for cached client * Make Worker component ready for cached client * Fix failing unit test * Address review feedback * Switch from MergePatchOrCreate to GetAndCreateOrMergePatch For the reasons explained in gardener#4057, MergePatchOrCreate is not safe to use without reading objects from the API server / cache first. Ideally we would switch to server-side apply to simplify such operations on controlled objects (e.g. extension resources), though we cannot leverage it for now because of several issues described in gardener#4122. * Remove *PatchOrCreate funcs As described in gardener#4057, *PatchOrCreate is easy to use incorrectly. Remove *PatchOrCreate funcs in order to minimize the risk of misuse. There might still be good use cases for this mechanism, though they are limited. If there is such a good use case, we can use it also without a helper func.
* Cleanup unused/dead code * Make EXPECTPatch easier to debug * Refactor extensions helper funcs This prefactoring performs several changes in the extension helper funcs: - the funcs directly work on the passed in objects instead of creating new objects via separately passed newObjFuncs. Passed objects are expected to be filled with the latest state the controller/component applied/observed/retrieved, but at least namespace and name. This way, controllers can keep working on a single in-memory object instead of retrieving the same object over and over again. - WaitUntilExtensionObjectReady additionally checks that the added timestamp annotation is present on the object to prevent false early exits when reading stale data (e.g. from a cached client). - makes naming more consistent and clearer This provides the following benefits: - makes the funcs ready to be used with cached clients, as they are able to properly handle stale data now - controllers/components automatically have the latest state of the objects present without retrieving them again from the API server. This will ease further refactorings and allows to safely use patches in a lot of cases instead of CreateOrUpdate (+RetryOnConflict). - the funcs are easier to use and comprehend: only the desired object needs to be passed, no need to pass newObjFuncs, namespace and name - the funcs are more similar to other helper funcs (e.g. CreateOrUpdate) and the mechanisms employed in e.g. c-r clients - no need to pass a client.Object to postReadyFuncs which needs to be casted again * Make BackupBucket controller ready for cached client * Make BackupEntry controller/component ready for cached client * Make ContainerRuntime component ready for cached client * Make ControlPlane component ready for cached client * Make Extension component ready for cached client * Make Infrastructure component ready for cached client * Make Network component ready for cached client * Make OperatingSystemConfig component ready for cached client * Make Worker component ready for cached client * Fix failing unit test * Address review feedback * Switch from MergePatchOrCreate to GetAndCreateOrMergePatch For the reasons explained in gardener#4057, MergePatchOrCreate is not safe to use without reading objects from the API server / cache first. Ideally we would switch to server-side apply to simplify such operations on controlled objects (e.g. extension resources), though we cannot leverage it for now because of several issues described in gardener#4122. * Remove *PatchOrCreate funcs As described in gardener#4057, *PatchOrCreate is easy to use incorrectly. Remove *PatchOrCreate funcs in order to minimize the risk of misuse. There might still be good use cases for this mechanism, though they are limited. If there is such a good use case, we can use it also without a helper func.
How to categorize this PR?
/area dev-productivity scalability
/kind cleanup
What this PR does / why we need it:
Similar to previous PRs, this PR works towards getting rid of the
DirectClient
.This one tackles usages in the extension components and makes them ready for cached clients.
Which issue(s) this PR fixes:
Part of #2822
Special notes for your reviewer:
c7bd017 is a prefactoring of the extension helper funcs, that is necessary for making the components ready for a cached client (see commit message for more details/reasoning).
The other commits perform the actual refactoring/adaption per component.
/squash
Release note: