donation of kube-rs to cncf

[clux]

Meta-issue via kubernetes/org#2792 (comment). We are applying for CNCF Sandbox status (and not for donation into kubernetes or kubernetes-client org).

old comparison of kubernetes org pros and cons - no longer relevant

As mention therein, I am happy for kube-rs to outlive my historically fleeting interest for things.
But, moving kube-rs to cncf under the kubernetes org comes with a bunch of pros and cons.

PROS:

• we become official, people trust us, we seem supported we get listed
• we avoid getting into a pointless competition with a naive, generated client under kubernetes/
• competition is incoming; judging by their tone, they will go ahead with the above without us
• gives the project future safety from @clux's disconnection from the world / potential delayed-onset insanity
• speculative: paves the way for tighter integration with sig-apimachinery ?
• more free CI infrastructure - github actions is free for us anyway
• In the case where a security change necessitates and API change, you will get notification during the embargo period and have more time to fix it.

CONS:

• need kubernetes bots and automation proposal: chubaofs to incubation stage cncf/toc#586 (not for CNCF)
• potential need to donate codegen - DCO/CLA audit cncf/toc#606 (not for CNCF)
• Needs a CLA (only for kubernetes orgs)
• being marked as official is arguably pointless when the rust community will treat us as the official client anyway
• Your major/minor releases will likely be tied to k8s releases - likely plays in with Add John Hillegass to CONTRIBUTORS.md cncf/toc#508
• Being tied to a foundation might limit our ability to stay afloat with sponsorship (linux foundation might take cuts)

Will create separate issues for the CONS under a new donation label so we can discuss specifics in a less cluttered way. This issue can be used for general points, and what we think about this.

A donation would follows this kubernetes process. No longer true. We are following the CNCF sandbox approach now.

Progress:

• we can make an org regardless for this and associated repos that might be easier for rust (where main 3 are admins)
• add a DCO, and slowly work towards getting to a point where we can legally license Update sandbox definition cncf/toc#585
• apply for CNCF sandbox
• add cncf best practice docs and processes Proposing Keptn to become an Incubation project cncf/toc#670
• refine our logo Note that all project maintainers must take LFC102 cncf/toc#570 (need svg logo before last step)
• submit pr to cncf/landscape
• cncf landscape issue for kube-rs: [SANDBOX PROJECT ONBOARDING] kube-rs cncf/sandbox#224

I am happy to discuss with CNCF and attempt do most the legwork here, if needed, and if this indeed feels worth doing to the community, and for us.

[nightkr]

being marked as official is arguably pointless when the rust community will treat us as the official client anyway

I agree that this seems likely for the existing "rust-kubernetes" community (huh, that feels weird to write out). But I suspect newcomers will gravitate pretty heavily towards the CNCF/K8s repo simply out of name recognition and trust.

[clux]

But I suspect newcomers will gravitate pretty heavily towards the CNCF/K8s repo simply out of name recognition and trust.

Yeah, initially at least. It's uncertain how far they'll get with the current approach though. How usable is it going to be without any generics, just flat structs, and no Resource trait.

The generated api code is literally:

pub async fn list_namespaced_replica_set(configuration: &configuration::Configuration, namespace: &str, pretty: Option<&str>, allow_watch_bookmarks: Option<bool>, _continue: Option<&str>, field_selector: Option<&str>, label_selector: Option<&str>, limit: Option<i32>, resource_version: Option<&str>, resource_version_match: Option<&str>, timeout_seconds: Option<i32>, watch: Option<bool>) -> Result<crate::models::V1ReplicaSetList, Error<ListNamespacedReplicaSetError>> 

like, ok. that's only going to discourage people. (and that's the biggest fear I have with this; they end up making rust look worse upon first inspection by releasing this).

[thomastaylor312]

FWIW all of us who work on DeisLabs projects will still support you either way. We have gone through the donation process (though not into the kubernetes org) to the CNCF with various projects so if you do choose to go that route we can help answer questions and look things over. I don't think we've done the relicensing thing before with one of our projects, but we know people who have and can reach out to them.

As an FYI, we are in the process of donating Krustlet and Krator, both heavy users of the crate, to the CNCF, so there is something to be said about having them all in CNCF-land together. I also think it does add some clout to the argument that the "naive, generated client" is probably not the best option.

So my thoughts on this issue: unfortunately being "blessed" by Kubernetes generally matters a lot within the community and most people will trust something in k8s over something that isn't officially there. However, I also know this project will continue to be successful even if it doesn't go to k8s – with the downside that there will be a communication/trust issue for people new to k8s + Rust. I personally would like to see this be the official Rust client as I think the additional support and community blessing will allow for this to be supported long term with a larger group of people (less individual burden). I do think that will take a bunch of work here in the next few months, but will be worth it in the long run. Like I said though, we will continue to support and use the crate either way!

[technosophos]

I'd reiterate that we're supportive regardless of the route you take.

Moving into CNCF is definitely a long project. I have done relicensing on one project, and it was a little bit of a pain. But CNCF gave us enough time to do it. So it wasn't a huge deal. I think that when we did Helm, it took us several months before we had all the i's dotted and t's crossed. (And to reiterate @thomastaylor312 again, we're happy to lend a hand wherever.)

I would add one other potential advantage:

• In the case where a security change necessitates and API change, you will get notification during the embargo period and have more time to fix it.

And one disadvantage:

• Your major/minor releases will likely be tied to k8s releases (and the community can be really demanding on that one)

[MikailBag]

Let me cc @Arnavion. Since k8s-openapi is an essential for kube to work, I guess they may be interested in this discussion.

[soenkeliebau]

Most of what I would have said has already been mentioned, but I'd still like to say that I am in support of at least investigating the option of moving this over to be an official project.

The main point for me is what @clux said above:

and that's the biggest fear I have with this; they end up making rust look worse upon first inspection by releasing this

Being "official" counts for a lot when people take decisions around which library to use, and I would much prefer this excellent crate be the official one :)

I think I speak for @lfrancke as well when I say that we are happy to help in any way that we can with this!

[clux]

Hey all. Thanks everyone for all the support on this. Here's a small update. From discussions around in cncf/toc#585 and cncf/toc#586 (even though we played a bit of devil's advocate in there) it's clear that:

The core 3 of us are +1 on doing the donation

I have moved us onto this new org (with a logo) for now. It might be temporary, but hopefully it looks a bit more professional either way.

I have tried to contact Brendan about some process questions, but I suspect he's busy. So am writing this down here for transparency - with my current thoughts - in the hope that other people can help out.

The key questions from our side

1. CLA

Is it viable to use the CNCF cla but with kube-rs owners as the owner during the process (so that we had something to fall back on if the donation for some reason didn't work out)?

After some legal advice, this seems likely to be problematic, given that the modification of the CLA means lawyers might have to look at it again. So might have to drop this, and accept that if the donation does not happen, then we don't have any rights (again). So guessing we should try to do the thing with CLA-assistant using CNCF's individual cla.

2. Direction w/o Steering

How we can control the direction of kube-rs without steering committee members, and what does this means for autonomy?

We are implementing things that already exists in client-go and other packages inside of this repo. Given kubernetes are already pushing for us to use their standardised codegen, it would be good to have this clarified.

3. Awkward bits in process

Can we elide @fejta-bot auto-closing stale issues and avoiding copyright headers?

The first one seems likely, people started opting out after this.

Headers, not sure. They seem to be inconsistent* throughout kubernetes-client org but they are consistent throughout kubernetes org. They do pointlessly inflate the repo by 10%, and feels pretty useless in this day and age, but maybe I am wrong.

This leads me to the last point.

4. Destination Org

Would we even be donating under kubernetes/ org? It feels slightly wrong to put it in kubernetes-client setups given we are also donating our controller runtime and crd machinery. On the other hand, helm has retained its org. Maybe this is the way to go if we need some freedom?

---

Anyway, I am keen to get this started if kubernetes steering is OK with it. We can probably make do with a variety of options for 1 + 4 provided official answers to 2 and 3 are considerate to our perspectives.

[spiffxp]

Hi! I found my way here by searching for "fejta-bot" since we've just switched to using "k8s-triage-robot". I'll offer my perspective as an emeritus kubernetes steering member, a current owner of the kubernetes github admin subproject, and as a current (SIG chair, WG organizer)

The first one seems likely, people started opting out after this.

I think the kubernetes community needs to have a healthy discussion to decide what's best for contributors and maintainers. The way it's implemented is a pretty boilerplate-heavy commenter job that uses github queries. If someone were to invest the effort to make that more concise as a dedicated tool, I suspect the low friction would reduce the contentiousness of individual subprojects (repos) deciding to use what works best for them.

How we can control the direction of kube-rs without steering committee members, and what does this means for autonomy?

Steering doesn't drive technical decisions, that's delegated to SIGs... you need a SIG to accept ownership. For decisions that span SIGs, SIG Architecture is generally used as the technical clearing house. Each SIG is different, but I have found if a subproject (repo) is well scoped, it's pretty laissez-faire.

Anyway, I am keen to get this started if kubernetes steering is OK with it.

Once you get licensing sorted out (super un-fun, I know), it's seems likely to me that you'll want to chat with SIG API Machinery since all of the other clients fall under their purview (ref: https://github.com/kubernetes/community/tree/master/sig-api-machinery#kubernetes-clients)

Headers, not sure.

@dims I feel like we got clearance to use something more abbreviated within the last N months, do you have context here?

[spiffxp]

On the other hand, helm has retained its org. Maybe this is the way to go if we need some freedom?

Helm is no longer part of Kuberentes. It's your call if being a CNCF-but-not-kubernetes project is what you'd prefer. I'm in the kubernetes camp, but I'm biased.

[BenTheElder]

I disagree that opting out of the lifecycle bot comments requires further effort in the tools kubernetes/kubernetes#103151 (comment), it is near entirely a policy question. The technical means are readily available, proven, and relatively low effort to enable.

Whether this will continue to be allowed is a question for Kubernetes Steering and SIG Contributor Experience.

[lfrancke]

I am not a lawyer.

I do however believe that your original plan for the CLA is sensible. Collect CLAs targeted towards yourself. As long as you have those it should be no issue at all to donate the code. I have not checked but I assume that almost all new projects/donations started their live outside of the CNCF and as such had CLAs (or similar) which target entirely different companies. Let's say you had started with a CLA from the beginning then you could still donate the code as long as the CLA permits it

Most CLAs out there are almost verbatim copies of the Apache CLA which includes the CNCF CLA. Lawyers will - in my experience - usually be fine and quick as long as you stay close to that (cncf/cla#5).

And about point 3: I hate the auto-close bot (I don't want to start a discussion, I assume everyone knows the arguments from both sides) so I'd be in favor of not having to adopt it.

[clux]

How we can control the direction of kube-rs without steering committee members, and what does this means for autonomy?

Steering doesn't drive technical decisions, that's delegated to SIGs... you need a SIG to accept ownership. For decisions that span SIGs, SIG Architecture is generally used as the technical clearing house. Each SIG is different, but I have found if a subproject (repo) is well scoped, it's pretty laissez-faire.

Thanks for the clarification @spiffxp . Sounds like we should perhaps try to maybe present kube-rs to SIG-APIMACHINERY. They at least normally handle the clients. I wonder if this might feel a bit out of scope to them though.

[clux]

Most CLAs out there are almost verbatim copies of the Apache CLA which includes the CNCF CLA. Lawyers will - in my experience - usually be fine and quick as long as you stay close to that (cncf/cla#5).

Thanks @lfrancke . I have tried to adapt the CNCF CLA with minimal modifications (documented here) as a gist in the hope that we can adapt CLA-Assistant for it. Ideally, I would ideally like to get some confirmation from CNCF so that we don't have to double request. But from a non-technical understanding of the legalese, it feels like it's just reassigning owners from me to them (if everything works out). But being at risk of engineer syndrome, it'd be good to see what footguns I am loading here.

[lfrancke]

Sounds good to me.
If you want to talk to a lawyer about this we'd be happy to pay to talk to ours but I'm not sure how much that helps because in the end the CNCF needs to decide.

That said: I'm pretty sure that the CLA you crafted (the one assinging everything to you personally) will be perfectly fine (legally) as it gives you permission to do exactly what you'd like to do.

[clux]

I appreciate that <3
And thanks again to everyone for offering so much support on this.

Hopefully CNCF can confirm this trivially. I've mailed info at cncf io with the subject CNCF CLA compatibility and project donation. With some luck they can give me a quick confirm given the documentation of the (kind of) unavoidable changes.

I just don't want to delay the CLA thing too much. It's already affecting whether or not I want to merge PRs from new contributors, and just want a thing that is good enough in place.

[Arnavion]

Do you have a resolution to kubernetes/org#2792 (comment) ? Specifically:

I think what is important is that you use the k8s-openapi code generator rather than simply picking up the code that is generated.

[clux]

Do you have a resolution to [...] k8s-openapi generator

Not at all. Nowhere in the short term does this feel realistic. While I have just toyed around with their generator, I don't see how we could possibly get it to do what k8s-openapi is doing for us. But my experience here is limited. @kazk has more experience on your end.

They did potentially seem open to both projects being donated, although I did not push that line of questioning further. Is that something you think you would consider?

[Arnavion]

My default position is to not donate it, but if it becomes a blocker for you I can consider it.

[clux]

Ok. It didn't sound like it would be an issue, so not going to push for it, but I appreciate it.

[caniszczyk]

Howdy, from CNCF here, I'm not sure what the ask is here :)?

If you're contributing your project directly to kubernetes, you'll need to enable the CNCF CLA checker/bot versus crafting your own custom CLA, info on how to do that is here: https://github.com/kubernetes/community/blob/master/github-management/setting-up-cla-check.md#setting-up-the-cncf-cla-check

[clux]

Howdy, from CNCF here, I'm not sure what the ask is here :)?

If you're contributing your project directly to kubernetes, you'll need to enable the CNCF CLA checker/bot versus crafting your own custom CLA, info on how to do that is here: https://github.com/kubernetes/community/blob/master/github-management/setting-up-cla-check.md#setting-up-the-cncf-cla-check

Hi @caniszczyk . Thanks for the help! The question is actually about the viability of this custom CLA (which more or less identical to the CNCF one), because our donation is not really sufficiently sketched out yet *:

• we don't know where we are donating (what org - kubernetes/ , kubernetes-client/ or a cncf external org)
• we don't know if we are donating (needs to be accepted by a sig)

But we'd like to start the process of collecting copyright and patent licenses so that we can expedite the process when/if we have everything sketched out.

[kazk]

It didn't sound like it would be an issue

I hope so, but as I wrote in #586 (comment), I think they're still misunderstanding how kube and k8s-openapi works.

Some relevant quotes and some notes:

All of the code generation for the "official" projects is centralized under:

kubernetes-client/gen

Moving the kube-rs project to that generator would be necessary in order to be an official client. (or maybe it would be "moving the kube-openapi project to that generator"?)

And I think the community would likewise benefit from any fix-ups that we have missed that kube-rs/k8s-openapi has done, moving them into the gen project would benefit all clients (and is the main reason why the centralization is worthwhile).

I don't think that it is necessary to centralize on the generator code itself (the dotnet library, for example uses a different generator, and there is little overlap between the various language generators anyway), but centralizing on the swagger download/patch/etc flow is necessary in my opinion so we make all of the fixes in a single place.

kubernetes/org#2792 (comment)

(There's only one bug fix up left that's still relevant for new versions. The official clients don't back port fixes as far as I know. All the other special fix ups are for generating a better Rust code, so I don't think it'll benefit them.)

They're most likely misunderstanding that k8s-openapi is a code generator kube uses. That's probably why they wrote the following:

I don't think that it is required for k8s-openapi to be donated, I think you can use it as an open source tool in the context of the gen repo just like we use the other code generators (which aren't donated either)

I think what is important is that you use the k8s-openapi code generator rather than simply picking up the code that is generated.

kubernetes/org#2792 (comment)

This comment makes more sense if they were talking about k8s-openapi and k8s-openapi-codegen (not required to donate), not kube and k8s-openapi. It's possible to make the output directory configurable and call k8s-openapi-codegen from a script in their gen repo to generate the code in k8s-openapi, but I doubt that's what they're saying (what's the point?). I think we should clarify this.

That said, the main goal is to have a central place to patch any bugs in spec. That can be done in other ways, like a separate tool to download and patch swagger.json that can be used by all clients, or some other way to share these fixes.

[caniszczyk]

@clux since you're Apache 2.0, we have no issues, we don't collect copyright in CNCF:
https://github.com/cncf/foundation/blob/master/copyright-notices.md#ownership-of-copyrights-in-cncf-project-contributions

We do recommend projects use DCO if they aren't using a CLA and most CNCF projects use that in lieu of one:
https://github.com/apps/dco

https://www.cncf.io/blog/2017/02/01/cncf-recommends-aslv2/

Anyways, hope that helps!

[thomastaylor312]

@caniszczyk I think one of the problems here is that there were no CLAs signed up to this point, so anything going into the CNCF needs to go get permission from every contributor. There is the cla-assistant, but is that the proper tool here in preparation for eventual acceptance into something like Kubernetes (see cncf/toc#585)? Or is this something that should wait until all the details are finalized on where this is going to land?

Did I summarize that properly @clux? Or just make it more confusing?

[clux]

Yeah, the retro-active approval here is the problem. I am fine with a DCO (in fact, with that linked github app it seems even simpler) if CNCF recommends that over a CLA (and it comes with less legalese), but I don't know what's a useful or recommended method for getting the retroactive sign-off equivalent for past commits.

[caniszczyk]

We don't need a previous CLA to get the project accepted in CNCF, we only care about the Apache license. All copyright is held by the existing contributors still. A CLA would only benefit you if you were on say MIT license and needed to change to Apache 2.0 to be accepted into CNCF (this is what projects like gRPC had to do). So you're all good here, you don't need a CLA now :)

…

On Tue, Aug 3, 2021 at 12:03 PM Eirik A ***@***.***> wrote: Yeah, the retro-active approval here is the problem. I am fine with a DCO (in fact, with that linked github app it seems even simpler) if CNCF recommends that over a CLA (and it comes with less legalese), but I don't know what's a useful or recommended method for getting the retroactive sign-off equivalent for past commits. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#584 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPSILV6RBV6F7RY3VACQTT3AONJANCNFSM5AAW4NKQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

-- Cheers, Chris Aniszczyk https://aniszczyk.org

[clux]

Some updates. We've added the DCO. So closed the first issue.

Second; we have a lot of openapi generation specific comments in this thread. Have tried to summarise the ask and concerns in cncf/toc#606 so we have a cleaner place to link to. People that's interested in that can continue over there.

[clux]

Summarising a small update here. I have submitted a CNCF sandbox application for kube-rs after a bit of research and due diligence work in cncf/toc#670. The CNCF approach puts less restrictions on us w.r.t. IP and awkward automation.

I hope that they might have a home for us under TAG-Runtime as that seems the most sensible to me from a quick scan.

As elaborated a bit before; I don't think we really fit in cleanly in the kubernetes-client org (where they have said they wanted us) with our scope, and also do not want us to be shoehorned in there as more of a second rate language while all of their sigs and main repos build focus on go. I would rather focus on helping to build a flourishing ecosystem outside of that garden, while maintaining some stricter care on the necessary boundary between the golang side (the apiserver and its api) and rust.

Hopefully, we can still cooperate with kubernetes/apimachinery on important issues around making this boundary as consistent and pain-free as possible.

[dims]

@clux i like it! +1 from me.

[clux]

donation is officially completed in cncf/sandbox#224 🎉