-
Notifications
You must be signed in to change notification settings - Fork 39.8k
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 dedicated UnixUserID and UnixGroupID types #44714
Use dedicated UnixUserID and UnixGroupID types #44714
Conversation
Hi @jamiehannaford. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with 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-bot ok to test |
API change in general approved as per linked thread. |
e5f1c87
to
3555bf9
Compare
3555bf9
to
19ae16f
Compare
949da60
to
3e5f194
Compare
@smarterclayton @yifan-gu @pmorie This is RFR. I know it's a ginormous changeset, but these API types touched lots of the codebase. If there's anything I can do to make reviewing easier (like breaking stuff up) please let me now! |
3e5f194
to
710d141
Compare
@smarterclayton @yifan-gu Is there any way to make this easier to review? Otherwise I might just close this PR, since it's unlikely folks with have time to review +100 files. Once we've figured out a strategy, I can rebase and fix conflicts/tests. |
Hm, strange. The bazel build is failing, but when you click on the Details link it says @thockin Any ideas what may be causing this? I've tried re-pushing and the same thing occurs. |
@k8s-bot bazel test this |
@jamiehannaford: The following test(s) failed:
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. |
/lgtm Comments from Reviewable |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jamiehannaford, thockin
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
@ixdy - bazel build fails immediately, no data. |
issue with prow. |
Automatic merge from submit-queue (batch tested with PRs 44590, 44969, 45325, 45208, 44714) |
@smarterclayton, @thockin: This PR included non-api types in the api type tree--that would have been good to call out in the review. |
Hrm, we already have types.UID |
I'm adding openapi definitions because that seems easier than unbreaking this. |
Workaround: #47753 |
Look like the OpenAPI changes is not the source of compatibility issue. It should be an old swagger 1.2 change. I will look into a solution. On things to call out in the review, can we make it a requirement to have separate commits for generated code. It is hard to find manual code inside this PR (I assume all types.go files, but I cannot be sure). |
I removed the release note because the PR is reverted |
/release-note-none |
Automatic merge from submit-queue (batch tested with PRs 47851, 47824, 47858, 46099) Revert 44714 manually #44714 broke backward compatibility for old swagger spec that kubectl still uses. The decision on #47448 was to revert this change but the change was not automatically revertible. Here I semi-manually remove all references to UnixUserID and UnixGroupID and updated generated files accordingly. Please wait for tests to pass then review that as there may still be tests that are failing. Fixes #47448 Adding release note just because the original PR has a release note. If possible, we should remove both release notes as they cancel each other. **Release note**: (removed by caesarxuchao) UnixUserID and UnixGroupID is reverted back as int64 to keep backward compatibility.
Automatic merge from submit-queue (batch tested with PRs 44590, 44969, 45325, 45208, 44714) Use dedicated UnixUserID and UnixGroupID types **What this PR does / why we need it**: DRYs up type definitions by using the dedicated types in apimachinery **Which issue this PR fixes** kubernetes#38120 **Release note**: ```release-note UIDs and GIDs now use apimachinery types ```
Automatic merge from submit-queue (batch tested with PRs 47851, 47824, 47858, 46099) Revert 44714 manually kubernetes#44714 broke backward compatibility for old swagger spec that kubectl still uses. The decision on kubernetes#47448 was to revert this change but the change was not automatically revertible. Here I semi-manually remove all references to UnixUserID and UnixGroupID and updated generated files accordingly. Please wait for tests to pass then review that as there may still be tests that are failing. Fixes kubernetes#47448 Adding release note just because the original PR has a release note. If possible, we should remove both release notes as they cancel each other. **Release note**: (removed by caesarxuchao) UnixUserID and UnixGroupID is reverted back as int64 to keep backward compatibility.
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Use single struct in internal type to reduce difference with external type **What this PR does / why we need it**: This PR reduces the differences between internal and external types by removing leftovers after revert of one of the changes. **Special notes for your reviewer**: We had `IDRange` in both types prior 9440a68 commit (#44714) that splitted it into `UserIDRange`/`GroupIDRange`. Later, in c91a12d commit (#47824) we had to revert these changes because they broke backward compatibility but `UserIDRange`/`GroupIDRange` structs were left in the internal type.
What this PR does / why we need it:
DRYs up type definitions by using the dedicated types in apimachinery
Which issue this PR fixes
#38120
Release note:
UIDs and GIDs now use apimachinery types