need to adopt kubernetes bots + security process + rules

[clux]

discussions about the potential process changes IF we donate the repo to CNCF (#584).

• Must adopt the Kubernetes Code of Conduct - cncf code of conduct #593

Pretty trivial thing to add. And more useful if that there's officially someone outside the project to oversee behaviour.

• Must adopt the CNCF CLA bot

Remarkably involved architecture behind this. But I assume it's just going to be another required check on the statuses. The CNCF signing process is pretty easy though (and likely something you'll do at some point if you ever contribute to anything inside kubernetes).

Even comparing it DCOs it stands out pretty well (DCOs require everyone to amend commits with --signoff)
The only thing I can see being nicer in the future would be something like Github Issue Forms and forcing users to sign there (if not already CLA signed).

• Must adopt all Kubernetes automation (e.g. /lgtm, etc)

lgtm looks like an easy enough thing.
But not sure about what the rest of the automation involves. The document is a bit opaque. The "issue goes stale after N days" automation is the worst thing though. So much unnecessary email spam, would ideally like to avoid that.

• All OWNERS must be members of standing as defined by ability to vote in Kubernetes steering committee elections. in the Kubernetes community

This feels pretty nebulous. I guess this means one or more of us (with admin on the repo) needs to join a steering committee?

• Repository must be approved by SIG-Architecture

Guess this is a last-step type of thing?

• Security process

Don't see this defined anywhere (just get stuff about podsecuritypolicy and securing kubernetes). But never seen particularly involved processes for this.

• Kubernetes Copyright Headers

This feels like a requirement form the 90s. A 16 line copyright header to all code files.
In practice this means our 14207 line rust codebase becomes almost 1400 lines longer (~10%!).
I guess we just get accustomed to scrolling past it though.

Edit: Kopyrights are listed as a should atm.

[clux]

Have updated the issue here with some details and my thoughts. The most annoying parts is probably the CLA and the Copyright headers in my book (but my hope is that they are all one-time costs that can be enforced by CI after), and hopefully we can still use github actions for our other release automation.

I'll try to verify more with CNCF, but before I proceed too deeply I need to know that the maintainers are OK with the idea of this extra overhead. As I said I am happy to try to investigate this myself (and have had many people reach out to help out with some of the process), but definitely cannot proceed without @kazk and @teozkr here :-)

Are you both OK with this move? Or would you prefer we make an organisation to avoid the overhead (like described in the parent issue).

[nightkr]

Are you both OK with this move? Or would you prefer we make an organisation to avoid the overhead (like described in the parent issue).

Overall I think this would be positive, but I'd be OK going either way. I don't want to pressure you into taking on the work here if you don't believe it's the right thing path (or even if it's "just" a matter of time, energy, and/or mental bandwidth).

• Must adopt the CNCF CLA bot

Remarkably involved architecture behind this.

Hah, that does almost feel like some kind of parody. But I suppose as long as running and maintaining it isn't our problem...

lgtm looks like an easy enough thing.

Yeah, not sure I see the value over the native GitHub flow here, but it shouldn't be a major problem either way.

But not sure about what the rest of the automation involves. The document is a bit opaque. The "issue goes stale after N days" automation is the worst thing though. So much unnecessary email spam, would ideally like to avoid that.

Yeah, not a big fan of @fejta-bot, at least not at the fairly minor scale that we're working out.

• All OWNERS must be members of standing as defined by ability to vote in Kubernetes steering committee elections. in the Kubernetes community

This feels pretty nebulous. I guess this means one or more of us (with admin on the repo) needs to join a steering committee?

As far as I believe, this is about voting in the elections to the steering committee, and is defined as being reasonably active in the K8s community (IIRC, 50+ "contributions" (issues, commits, PRs, reviews, etc) or a special exemption for off-GH activity).

I'm not sure about @clux or @kazk, but I personally don't meet that bar (at least not before the merger goes through, if it does).

• Kubernetes Copyright Headers

Hopefully this would just be a CI issue, although I do worry slightly about whether this would disincentivize splitting up modules.

[kazk]

Are you both OK with this move? Or would you prefer we make an organisation to avoid the overhead (like described in the parent issue).

Yeah, I'm OK with the move. Donating seems like the only way to prevent a naive official Rust client :/
Is it easier to move to kube-rs org first to set up automation? I think it's a good idea to create an org even if we decide not to donate.

By the way, I feel like they're still misunderstanding how kube and k8s-openapi works based on their replies, so we should make that clear and confirm we can become official before doing anything. They sound like they think k8s-openapi is a code generator tool. k8s-openapi-codegen is probably not what they're expecting either.

The "issue goes stale after N days" automation is the worst thing though. So much unnecessary email spam, would ideally like to avoid that.

Yeah, I'm not a fan either :(

• Kubernetes Copyright Headers

This is annoying :( JavaScript client doesn't seem to have them, so we might be able to avoid them. https://github.com/kubernetes-client/javascript/tree/master/src

I personally don't meet that bar (at least not before the merger goes through, if it does).

Same here.

[clux]

Sounds like we need to clarify a few things with regards to relations with k8s-openapi and what we can expect in terms of standing.

I feel we should be given some token power here given that we practically help steer the rust community's involvement with k8s and are dependencies of future CNCF projects.

I think it's a good idea to create an org even if we decide not to donate.

I will certainly want to create an org if we do not donate. We can have other associated repos (controller-rs, version-rs) and whatever other related tooling we might need. It makes it easier to customise access (currently I can't seem to give anyone else admin for instance), and it makes the project seem less like "just some guy's side-project".

But not sure I should do it before trying the donation route though. It will leave associated repos orphaned, and it will probably mean a CLA stepping stone (adopting a similar CLA to CNCF that defers to owners as either me, or "kube-rs org owners"). But maybe that's actually a good idea until we can get clarity (and it will likely take us some time to get approval from everyone anyway).

copyright headers disapproval

Good find about the javascript client. It seems the same is true also for at least the C and Haskell clients, so this doesn't look like a hard requirement.

@fejta-bot disapproval

I'm leaning towards a requirement to be able to opt out of @fejta-bot to do this. The more I think about the auto-closing of stale issues feels like a worse signal than what is made up for by the positive signal of being official. We're also not alone in this: 1, 2, 3, 4.

Anyway, I'll try to get more answers and update the thread as I go along (even though I can only dedicate a bit of time to this every week). I think the closer cooperation of same-org would be beneficial, provided the associated process quirks (where we seem to have identified the most problematic ones) can be minimised.

[clux]

Some devil's arguments for the potential org alternative here. Because it feels like we should explore the other side a bit as well.

1. Full org control. No legacy automation that's going against newer github features.

2. "Official". An own org helps a ton by itself for image. Most big rust projects have their own org with related tech anyway. Big users already back us, and are likely to continue backing us (judging from the previous thread).

3. Rust cohesion. Kubernetes CONTRIBUTING docs point to #kubernetes-client on kubernetes slack (a channel with even less activity than our channel). We'd have to reconsider ties with the tokio discord (which has been very helpful with cross-pollination of ideas) if we move to CNCF.

4. Autonomy. If we donate, it's probably a one-way transaction. We can't go back to developing outside AFAIKT. If sig-apimachinery won't give us any standing and will prevent us from going in special directions because it increases their operational overhead, then that's not great.

5. We could all use github sponsorship as a way to help finance development. That would be difficult within the CNCF, where they legally take all the credit (while putting up auto-closing-issue bots) and expect volunteers to maintain things forever (probably leading to the issue bankruptcy they are having).

6. If we could be blessed by SIG-APIMACHINERY as a recommended client under this separate crown (and them not competing with a naive client), then I'd personally prefer it to the cruft.

7. Potential reversibility. We could possibly reverse/upgrade the decision from own-org to official within-kubernetes later. It might be an easier sell 2 years down the line if they've released something no-one uses. Maybe at that point we'd feel more "done" with its design, and have a CLA that makes the transfer quick.

8. Having n clients under the kubernetes-client org seems a bit pointless to users (who come looking for the one in their language usually), and not super beneficial to maintainers when the client is written in a non-standard way (us). I.e. not sure how forthcoming the current maintainers client maintainers would be to help if we are seen as a design snowflake. This objection goes away if we end up under kubernetes root org (where client-go resides though).

[clux]

I have moved us to my new kube-rs org and invited the 3 of us as owners.
Maybe I can rename it to kube as kube-rs/kube feels possibly cleaner than kube-rs/kube-rs?

Anyway this is possibly only a stop-gap measure, but it's a cleaner setup than under my personal account. It's probably going to be a nicer looking home for now while we setup the big CLA issue and wait for people to respond (that might take months).

I'll change some links later (but we get auto-redirects from github).

[clux]

The legal advice we got in the main thread might only have applied to CNCF donation, and not to the kubernetes org (which seems to be lagging behind on many of these process points).

I did a question in the kubernetes/org thread about where we would end up given our setup, and it seems we either:

• join the kubernetes-client org managed by sig-apimachinery
• apply to become a cncf sandbox project

Based solely on how the kubernetes-client org feels, and how awkward we would sit in there, I am inclined to not go for the first one anymore. I want rust to be a first class language in kubernetes, not a "oh, there's also a rust client in this second-rank org". We would also need to get all contributors to sign the CLA for that option.

On the downside, there's the chance that they won't mark us as official that way and go ahead with their naive client anyway. But if we are a CNCF project, then we can maybe get them to list us in a different capacity on that page, and/or crosslink our project from any official rust experimental project (just like they hotlink client-go from their experimental & abandoned openapi go client in there). Anyway, I would hope they at least would be so kind as to tell us that.

Pinging here to avoid the official parent thread for now. If any of you in @kube-rs/core-maintainers have any updated thoughts/feelings please share.

[nightkr]

From the sound of it there it almost sounds like it overlaps more with k8s-openapi than with kube-rs. So I guess the question then would be whether we'd still have access to the same traits and stuff that k8s-openapi provides (and whether we'd like to rebase on $OFFICIAL_K8S_LIBRARY rather than k8s-openapi).

[clux]

That is true. k8s-openapi (with it's feature-avoidable client feature) fits better in there than us, and we could actually build on top of it. Maybe if we get somewhere with the prost experiments that would be a good thing to put there, and use that as a springboard back to kube-rs for anything except basic functionality.

[clux]

Haven't dedicated more time to this yet, but still think the CNCF sandbox path is more suited to kube, while rebasing on k8s-pb long term if possible (and see if that's more appealing to kubernetes core).

Anyway going to close this issue as a wontfix, and instead start a follow-up for CNCF sandbox and comment upstream. The legal advice that we got in the parent issue only seemed to apply to CNCF anyway, and am not particularly keen on going the full CLA in here anymore.