-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Add generics policy for kubernetes #6693
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
Conversation
c74b1ee
to
374ad75
Compare
Consider if proposed generics pull requests improve maintainability and readability. | ||
|
||
The current generics implementation is known to have some performance issues | ||
depending on usage: consider requesting benchmarks before / after the changes. |
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.
added
/assign @johnbelamaric @derekwaynecarr |
374ad75
to
1553956
Compare
/retitle Add generics policy for kubernetes |
1553956
to
d76520c
Compare
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.
looks like a good starting point, had a couple questions
sig-architecture/generics.md
Outdated
|
||
Generics may be used in Kubernetes starting in v1.25 | ||
|
||
Avoid generics when writing bug fixes until v1.24 is [out of support][version-support], to ease |
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.
+1 to this guidance
in case we ran into other issues and needed to roll back to unblock the release. | ||
Now that v1.24.0 is out, use of generics should be unrestricted. | ||
|
||
# Generics Policy |
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.
should we have guidance for use of generics in our libraries consumed by multiple branches of kubernetes, like k8s.io/utils, k8s.io/kube-openapi, etc? xref discussion in kubernetes/utils#243 (comment)
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.
Great point, we only discussed this from the staging library angle previously.
We should add a note similar to the bug fixes guidance, but as a hard requirement, I think.
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.
I rewrote this a bit to position limitations until v1.24 is out of support and address this point.
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.
looks fine as a starting point. we could maybe relax the guidance to allow use of generics in those repos in ways that would still support go1.17 (go-version conditional files, etc), but I'm not familiar with how possible/fiddly that is... we'd want to be really confident in the implications before doing so, I guess
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.
Even if technically possible (I think so with build tags?) I don’t think we want to allow this versus waiting a few more releases just because it’s very similar to starting to support multiple branches of these libraries from a support perspective and we don’t do that today in any I can think of.
- Consider if proposed generics pull requests improve maintainability and readability. | ||
|
||
- The current generics implementation is known to have some performance issues | ||
depending on usage: consider requesting benchmarks before / after the changes. |
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.
are there any links to the known perf issues to give hints to where generics might not be appropriate yet?
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.
I didn't want to put information into this doc that would become out of date as go improves and measuring > "knowing", but in the initial go1.18 implementation at least generics are only partially monomorphized by GCShape and have an additional indirection at runtime for the method dictionaries.
So they pretty universally cost more, but that may still be justified by type safety and maintainability if you can keep it out of hot paths => avoid developer pain from code generation.
https://planetscale.com/blog/generics-can-make-your-go-code-slower
I'd like to think a suitable usage for now looks like:
https://github.com/kubernetes-sigs/oci-proxy/blob/f60b1fc751c6a65225aee8f9363d32cb8e0aa54b/pkg/net/cidrs/triemap.go
(not in hotpath, still typesafe, used internally)
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.
I didn't want to put information into this doc that would become out of date as go improves and measuring > "knowing"
fair enough
d76520c
to
585e120
Compare
lgtm |
I like it! |
sig-architecture/generics.md
Outdated
In Kubernetes v1.24 we shipped Go 1.18 (which adds support for generics) | ||
rather late in the release cycle, so we temporarily prohibited using generics | ||
in case we ran into other issues and needed to roll back to unblock the release. | ||
Now that v1.24.0 is out, use of generics should be unrestricted. |
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.
nit: this says "[...] use of generics should be unrestricted" but then below we now say "Generics may be used in Kubernetes starting in v1.25, with the following restrictions applying only until v1.24 is [out of support]"
may simply change this to "[...] use of generics should be allowed."
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.
done.
as discussed in the last SIG Architecture meeting
585e120
to
66d09b8
Compare
/approve /hold cancel Let's merge and iterate if needed |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: BenTheElder, dims 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 |
saving some urls here for later :) |
as discussed in the last SIG Architecture meeting
Which issue(s) this PR fixes:
cc @dims @johnbelamaric