-
Notifications
You must be signed in to change notification settings - Fork 70
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
chore: generate applyconfigurations for custom resources #217
Conversation
/hold let's not merge this before the v0.7.0 release |
Signed-off-by: Erik Godding Boye <[email protected]>
The 0.7.0 release is history. /unhold |
/retest |
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
/approve
This doesn't seem to runtime impact currently - making it very easy to approve. Thanks for looking into this, I'm interested in following it!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: SgtCoDFish The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test pull-trust-manager-verify |
I think the migration to SSA in this project made the code harder to read/understand. 😉 While the support for SSA in the controller-runtime client is limited at present, ref. kubernetes-sigs/controller-runtime#347, I am convinced that we can do better.
Generating applyconfigurations with controller-gen is in the making, ref. kubernetes-sigs/controller-tools#818 and kubernetes-sigs/controller-tools#536, but it's a complex task that still needs some work.
In the meantime, I suggest generating applyconfigurations using the upstream generator that we can use in our controllers. I also suggest exporting the generated applyconfiguration types, even if I think client types should be available without depending on the operator module - creating a potential dependency-hell. This has been a long-standing issue in cert-manager that I hope can get some progress soon.
/cc @inteon @SgtCoDFish