Move generators to staging/src/k8s.io/kube-gen

[sttts]

Reason number one for people trying the impossible of vendoring kube: reuse of the generators.

[sttts]

/cc @maleck13 ptal

[sttts]

/cc @maleck13 ptal

[k8s-ci-robot]

@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:

/cc @maleck13 ptal

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.

[k8s-ci-robot]

@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:

/cc @maleck13 ptal

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.

[deads2k]

/lgtm

(It won't merge without a top level approver.)

I'm definitely a fan.

[deads2k]

/lgtm

(It won't merge without a top level approver.)

I'm definitely a fan.

[maleck13]

@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.

[maleck13]

@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.

[deads2k]

@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.

[deads2k]

@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.

[lavalamp]

Is this ready to go? I am happy to approve it

[lavalamp]

Is this ready to go? I am happy to approve it

[sttts]

@lavalamp looks like some verify errors are left. Will take care of them tomorrow. Feel free to approve it now :)

[sttts]

@lavalamp looks like some verify errors are left. Will take care of them tomorrow. Feel free to approve it now :)

[caesarxuchao]

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.

[caesarxuchao]

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.

[deads2k]

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.

[deads2k]

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.

[lavalamp]

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

[lavalamp]

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

[k8s-merge-robot]

[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 /approve no-issue

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

• OWNERS [lavalamp]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[k8s-merge-robot]

[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 /approve no-issue

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

• OWNERS [lavalamp]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[sttts]

Fixed the verify issue: client-gen -t also needed an output base to find its test group. Otherwise, nothing serious changed.

[sttts]

Fixed the verify issue: client-gen -t also needed an output base to find its test group. Otherwise, nothing serious changed.

[sttts]

/retest

[sttts]

/retest

[sttts]

/retest

[sttts]

/retest

[sttts]

/retest

[sttts]

/retest

[deads2k]

/retest

[deads2k]

/retest

[k8s-merge-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[k8s-merge-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[sttts]

/retest

[sttts]

/retest

[k8s-merge-robot]

Automatic merge from submit-queue (batch tested with PRs 49114, 48810)

[k8s-merge-robot]

Automatic merge from submit-queue (batch tested with PRs 49114, 48810)

[k8s-ci-robot]

@sttts: The following tests failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
pull-kubernetes-federation-e2e-gce	660ada4	link	/test pull-kubernetes-federation-e2e-gce
pull-kubernetes-e2e-gce-etcd3	660ada4	link	/test pull-kubernetes-e2e-gce-etcd3

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]

@sttts: The following tests failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
pull-kubernetes-federation-e2e-gce	660ada4	link	/test pull-kubernetes-federation-e2e-gce
pull-kubernetes-e2e-gce-etcd3	660ada4	link	/test pull-kubernetes-e2e-gce-etcd3

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.

[mbohlool]

Do you plan to keep this in the staging/ forever? As far as I can tell, we can't vendor this in, without some boring hack, if we plan to develop it in its own repo (godep does not allow importing main packages).

[mbohlool]

Do you plan to keep this in the staging/ forever? As far as I can tell, we can't vendor this in, without some boring hack, if we plan to develop it in its own repo (godep does not allow importing main packages).

[sttts]

if we plan to develop it in its own repo

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?

[sttts]

if we plan to develop it in its own repo

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?

[mbohlool]

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.

[mbohlool]

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.