Move generators to staging/src/k8s.io/kube-gen #49114
Conversation
|
/cc @maleck13 ptal |
|
@sttts: GitHub didn't allow me to request PR reviews from the following users: maleck13, ptal. Note that only kubernetes members can review this PR, and authors cannot review their own PRs. 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. |
|
/lgtm (It won't merge without a top level approver.) I'm definitely a fan. |
|
@sttts Am i understanding correctly that this would allow us to vendor the generator pkgs in a similar way to the apiserver and apimachinery. If so I love it. Was wondering recently how to keep the versions in sync and it seemed vendoring k8s was the only way. |
Yes, that's the intent here. There is more work to do to make them truly re-usable, but this would be a good first step. |
|
Is this ready to go? I am happy to approve it |
|
@lavalamp looks like some verify errors are left. Will take care of them tomorrow. Feel free to approve it now :) |
|
One question, do we need to set up the publish robot to sync the repo, or are we going to move it its own repo and vendor it back? I think the latter is preferred, since those generators are relatively stable. |
I don't feel strongly either way, but I do think we have a significant amount of work to do on them to make them re-useable before we move them out of tree. I suspect they'll be fast moving until we complete the work of making them flag driven instead of hardcoded and I'd want to be certain that they work with kube during that process. I could even see an argument that says we should never have a level of the kube generators that doesn't generate working code for us and developing them in an authoritative staging repo ensures that. |
|
Since this already needs a rebase I went ahead and approved #49055. I'll approve this ahead of time and then you'll just need an lgtm after you rebase. /approve |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: deads2k, lavalamp, sttts No associated issue. Update pull-request body to add a reference to an issue, or get approval with The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
sttts
force-pushed the
sttts:sttts-kube-gen
branch
2 times, most recently
from
de46c48
to
28b459c
|
Fixed the verify issue: |
|
/retest |
|
/retest |
2 similar comments
|
/retest |
|
/retest |
|
/test all [submit-queue is verifying that this PR is safe to merge] |
|
/retest |
|
Automatic merge from submit-queue (batch tested with PRs 49114, 48810) |
k8s-github-robot
merged commit c3a9270
into
kubernetes:master
|
@sttts: The following tests 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. |
|
Do you plan to keep this in the |
In the worst case we can manually keep the main package in the vendor tree. It's a godep issue, not a vendor-experiment issue. I hope we find a way to move to golang/dep in the midterm future. Is this still a problem there? |
|
Probably yes. Though I didn't give it a try. Problem is for any dependency system, the best way to build dependency tree is import clauses and you cannot import a main package. That is a go thing as far as I understand. Unless there is a way in golang/dep to specify manual dependencies. |
Reason number one for people trying the impossible of vendoring kube: reuse of the generators.