Move sample-controller out of staging

[kubernetes]

Move sample-controller out of staging

[sttts]

It also serves the purpose of test bed for k8s.io/code-generator and other machinery.

And with many people still following this style intentionally, there is value to keep it. I would be fine with some links in the readme to get to know about the other controller building tools.

[sttts]

Who will maintain it outside of k/k? I.e. rebase it to latest client-go each release. In k/k we basically get this for free.

[nikhita]

@pwittrock Yeah, rebasing it to the latest staging repos (api, apimachinery, client-go, code-generator...) is a huge trouble :( and that's the reason we have it in staging. Also, that's why repos like cluster-bootstrap, cloud-provider are being added into staging today.

Closing this issue. Please reopen if needed.
/close

[k8s-ci-robot]

@nikhita: Closing this issue.

In response to this:

@pwittrock Yeah, rebasing it to the latest staging repos (api, apimachinery, client-go, code-generator...) is a huge trouble :( and that's the reason we have it in staging. Also, that's why repos like cluster-bootstrap, cloud-provider are being added into staging today.

Closing this issue. Please reopen if needed.
/close

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.

[DirectXMan12]

@nikhita @sttts we can probably maintain this as part of the kubebuilder/controller-runtime/controller-tools ecosystem. We probably don't want to actually encourage people to write controllers from scratch like this, copying and pasting all this code around.

This project already falls under the server-sdk subproject, which also is responsible for KB, CR, and CT, so it seems reasonable to have the KB maintainers maintain the sample as a consumer of CR/CT.

WDYT?

[DirectXMan12]

And with many people still following this style intentionally, there is value to keep it

If people (outside the SIG API Machinery core maintainers) follow this style intentionally for non-legacy reasons, I'd very much like to know why (not trying to be sarcastic there -- I'm genuinely curious as to gaps in CR/CT). AFAICT, most new Go controller projects (both within the kubernetes-sigs umbrella and in the broader community ecosystem) are based on controller-runtime (and several legacy projects have been looking at migrating, IIRC), so significant blockers to further adoption would be super-useful to know.

It also serves the purpose of test bed for k8s.io/code-generator and other machinery.

I'd argue that that reason isn't sufficient for calling this "sample-controller" -- we shouldn't call this repo the sample controller any more than we'd call a controller written without client-go the sample controller. "Sample" implies "this is a good way to start writing your new controller", and I believe we have ample evidence that that's not the case.

It's fine (and a good idea) for us have a testbed for k8s.io/code-generator, but unless we're seriously going to recommend people copy this code to write controllers, then the testbed for k8s.io/code-generator should be "k8s.io/code-generation-test-project" or "k8s.io/code-generator/test-project", or somesuch.