-
Notifications
You must be signed in to change notification settings - Fork 595
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
Use the manager client in the parser #2250
Conversation
1b94211
to
bcb8916
Compare
bcb8916
to
aad7b6b
Compare
Remaining failures should be resolved by #2253 DB-less passed, and this change should be the same across both deployment types, so the PoC should be good to go. |
2165989
to
bdd784f
Compare
Use the manager client to retrieve resources for the parser rather than the store. WIP currently only does this for networking v1 Ingresses. WIP all parser unit tests are disabled, because they now require a Kubernetes client to run Build().
bdd784f
to
c6c5e5d
Compare
It seems we've left this one for a while, given our current state and that we have a follow up issue are we OK to close this? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Copied to my fork in case we ever want to review the old POC |
What this PR does / why we need it:
This is a PoC to strip the store package out of the parser. Instead of using the store, the parser will
List()
resources directly from the manager client.This WIP only does so for Ingress v1 resources. It does not yet attempt to filter these resources by class. It disables parser unit tests because
Build()
(which every parser unit invokes) now needs a manager client, and I didn't want to deal with converting a ton of test cases to https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/client/fake for the PoC.Special notes for your reviewer:
The relationship between UpdateKongAdminSimple, the KongUpdater function type, and things that use them remain confusing and somewhat annoying to refactor around. IDK if we have actual intent to implement alternative updaters (AFAIK, the original rationale for how this is structured), but we haven't so far. We may want to consider simplifying it.