🌱 Remove reliance on controller-runtime scheme builder #9045
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
the
size/M
|
I think you're right, i don't think it does need to be exported. Currently we are using it in the test builders so that we can access the |
JoelSpeed
force-pushed
the
drop-schemebuilder-pattern
branch
from
f65dc3f
to
e0c9cdb
Compare
|
@killianmuldoon I made the scheme builder private, I think this is good to go if you're happy with the API diff |
|
Nice improvement 👍 Should we track doing the same for the other API's we define (maybe separate PR then / let's have an issue for that)? |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. Git tree hash: cf355907c165e22695fddef078d900485e255f17
|
Yes, what do you think is the best way to track this? I can either update the linked issue for this to create a checklist for APIs to move across, or I can duplicate the issue for each group. I lean towards the first so that we have a single top level tracker but I'm easy if other prefer the alternative approach |
Both is totally fine I think. I'm tend towards updating the linked issue with a checklist 👍 . |
|
/test |
|
@killianmuldoon: The
The following commands are available to trigger optional jobs:
Use
In response to this:
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. |
|
/test pull-cluster-api-e2e-full-main /hold /lgtm |
k8s-ci-robot
added
the
do-not-merge/hold
k8s-ci-robot
added
the
approved
| ) | ||
|
|
||
| func addKnownTypes(scheme *runtime.Scheme) error { |
There was a problem hiding this comment.
Q: Isn't this all the same as just:
func AddToScheme(s *runtime.Scheme) {
s.AddKnownTypes(GroupVersion, objectTypes...)
metav1.AddToGroupVersion(s, GroupVersion)
}Would it be simpler to just define the func?
(seems a lot easier to understand to me, but maybe I'm missing something)
There was a problem hiding this comment.
This pattern seems to be common if you look at say core/v1 or any other API package, so I was just following the usual pattern.
In those other APIs the schemebuilder is exported though, perhaps we should be leaving ours exported for consistency?
There was a problem hiding this comment.
No strong opinion from my side (@vincepri?)
I was just wondering if we have to go through the schemeBuilder if we only export the AddToScheme func as we could do that in a simpler way.
|
One nit. Let's keep the hold just to discuss that one |
k8s-ci-robot
removed
the
lgtm
k8s-ci-robot
added
size/L
|
Added some documentation to explain the new pattern, PTAL |
|
@JoelSpeed: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. Git tree hash: 90cd36d59ab67ec1d6b2fa806f58ec48b8a60e88
|
|
@sbueringer - if you're happy with the current state I think we can unhold this - just waiting on #9045 (comment) |
|
Let's go ahead with this. It seems like unnecessary complexity if we don't expose the schemeBuilder. But we can still implement my suggested change later if we ever want to, it doesn't change anything that we export. Might be wort opening an issue in the kubebuilder repository as a follow-up. Maybe they want to change the way they generate API files so other folks benefit from reduced dependencies as well. Thx for the nice documentation!! /approve |
k8s-ci-robot
removed
the
do-not-merge/hold
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: killianmuldoon, sbueringer 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 |
|
|
||
| [scheme]: https://pkg.go.dev/k8s.io/apimachinery/pkg/runtime#Scheme | ||
|
|
||
| By default, Kubebuilder will provide you with a scheme builder like: |
There was a problem hiding this comment.
Do we have an issue in Kubebuilder to try steer away from the current pattern?
There was a problem hiding this comment.
Not yet, I'll make one
| In general, you should minimise the imports within the API folder of your package to allow your API types | ||
| to be imported cleanly into other projects. | ||
|
|
||
| To mitigate this, use the following schemebuilder pattern: |
There was a problem hiding this comment.
cc @furkatgofurov7 In case we might want to include this as an optional action item in the v1.6 release
There was a problem hiding this comment.
@vincepri For the provider migration doc, right? Sounds like a good idea!
There was a problem hiding this comment.
@vincepri @sbueringer +1 to add it to the provider migration doc.
Opened #9146 to cover that, PTAL and let me know what you think, thanks!
|
/area api |
What this PR does / why we need it:
To work towards #9011, we need to remove the reliance on controller-runtime from the API packages.
This updates the scheme building methods in the core v1beta1 API group to rely only on API machinery types and not controller runtime types.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #