It updates controller-runtime and the Kubernetes dependencies to the latest versions
It removes most of pkg/controller - I plan to move this (back) into c/c
I'd like to upgrade controller-runtime, because the latest versions have some promising functionality that may help with realtime compositions. You can now stop an informer within a cache, and stop an informer's event handlers. I believe this could eliminate the need for us to create a cache per controller, thus eliminating the need for the GVK routed cache etc.
Unfortunately there are some breaking changes around the source.Source interface in the latest version of controller-runtime. They break the engine and GVK routed cache implementations.
Rather than refactor things here and in c/c to accommodate the breaking changes, I'd like to move everything into c/c. As far as I know c/c is the only consumer of pkg/controller (except for the Options struct that isn't moving). It's a pain to have to update them in c/cr and then bump c/c. (My bad - I moved the engine here in the first place.)
I'll open a c/c PR that copies pkg/controller.
Deleting these is a breaking change, but I don't think it will affect anyone in practice. Based on the below search, no-one but c/c is actually using these types.
Description of your changes
This PR does two things:
pkg/controller- I plan to move this (back) into c/cI'd like to upgrade controller-runtime, because the latest versions have some promising functionality that may help with realtime compositions. You can now stop an informer within a cache, and stop an informer's event handlers. I believe this could eliminate the need for us to create a cache per controller, thus eliminating the need for the GVK routed cache etc.
Unfortunately there are some breaking changes around the
source.Sourceinterface in the latest version of controller-runtime. They break the engine and GVK routed cache implementations.Rather than refactor things here and in c/c to accommodate the breaking changes, I'd like to move everything into c/c. As far as I know c/c is the only consumer of
pkg/controller(except for theOptionsstruct that isn't moving). It's a pain to have to update them in c/cr and then bump c/c. (My bad - I moved the engine here in the first place.)I'll open a c/c PR that copies
pkg/controller.Deleting these is a breaking change, but I don't think it will affect anyone in practice. Based on the below search, no-one but c/c is actually using these types.
https://github.com/search?q=%22github.com%2Fcrossplane%2Fcrossplane-runtime%2Fpkg%2Fcontroller%22&type=code&p=5
I have:
make reviewable testto ensure this PR is ready for review.How has this code been tested
It's been covered pretty extensively by unit and E2E tests in https://github.com/crossplane/crossplane/pull/5651.