-
Notifications
You must be signed in to change notification settings - Fork 39.7k
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
Tag structs as atomic #100684
Tag structs as atomic #100684
Conversation
/triage accepted |
/test pull-kubernetes-integration |
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
/assign @liggitt |
Can you maybe squash some of these commits? |
Squashed |
/retest |
/test pull-kubernetes-e2e-kind |
two questions, lgtm otherwise |
Addressed comments. Marked |
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Jefftree, liggitt 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 |
@@ -5362,6 +5374,7 @@ type ServiceProxyOptions struct { | |||
// Instead of using this type, create a locally provided and used type that is well-focused on your reference. | |||
// For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 . | |||
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object | |||
// +structType=atomic | |||
type ObjectReference struct { |
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.
Per discussion with @apelisse it seems wrong to make ObjectReference
atomic, because the users specify the apiVersion/Kind/Namespace/Name, and the controller-manager updates the UID. For example, users should be able to specify PV's .spec.claimRef
and apply it via SSA, but that will conflict with the PV controller which manages .spec.claimRef.uid
.
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.
Good catch Janet, thanks for letting us know. @alexzielenski is looking at it.
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.
Related too, unsurprisingly: fluxcd/flux2#2827
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
See review of all occurrences of the term "selector" in types.go files
Addresses comments from #100131
Which issue(s) this PR fixes:
Fixes #97970
Related to #97989
Special notes for your reviewer:
I'm not sure what kind of tests we need for these. There are already tests for the generic atomic annotation, I feel like we shouldn't need to test every instance of it. Some are transparent changes because the types are only used in lists that are already atomic.
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: