- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
need to adopt kubernetes bots + security process + rules #586
Comments
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). |
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).
Hah, that does almost feel like some kind of parody. But I suppose as long as running and maintaining it isn't our problem...
Yeah, not sure I see the value over the native GitHub flow here, but it shouldn't be a major problem either way.
Yeah, not a big fan of @fejta-bot, at least not at the fairly minor scale that we're working out.
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).
Hopefully this would just be a CI issue, although I do worry slightly about whether this would disincentivize splitting up modules. |
Yeah, I'm OK with the move. Donating seems like the only way to prevent a naive official Rust client :/ By the way, I feel like they're still misunderstanding how
Yeah, I'm not a fan either :(
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
Same here. |
Sounds like we need to clarify a few things with regards to relations with 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 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).
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.
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. |
Some devil's arguments for the potential org alternative here. Because it feels like we should explore the other side a bit as well.
|
I have moved us to my new 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). |
taken from helm. seems best practice to just link to the root one, and use lowercase naming (both helm and kubernetes/client-go does this)
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:
Based solely on how the 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. |
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). |
That is true. |
Haven't dedicated more time to this yet, but still think the CNCF sandbox path is more suited to kube, while rebasing on Anyway going to close this issue as a |
discussions about the potential process changes IF we donate the repo to CNCF (#584).
Pretty trivial thing to add. And more useful if that there's officially someone outside the project to oversee behaviour.
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).
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.
This feels pretty nebulous. I guess this means one or more of us (with admin on the repo) needs to join a steering committee?
Guess this is a last-step type of thing?
Don't see this defined anywhere (just get stuff about podsecuritypolicy and securing kubernetes). But never seen particularly involved processes for this.
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.
The text was updated successfully, but these errors were encountered: