Migrate existing repo to kubernetes-client (kube-rs)

[alberthuang24]

New Repo, Staging Repo, or migrate existing

migrate repository

Requested name for new repository

rust

Which Organization should it reside

kubernetes-client

If not a staging repo, who should have admin access

@brendandburns @clux

If not a staging repo, who should have write access

@brendandburns @clux

If not a staging repo, who should be listed as approvers in OWNERS

@brendandburns @clux

If not a staging repo, who should be listed in SECURITY_CONTACTS

@brendandburns @clux

What should the repo description be

rust client library for kubernetes

What SIG and subproject does this fall under in sigs.yaml

sig-api-machinery kubernetes-client

Approvals

kubernetes-client/gen#192

kubernetes-client/gen#194

Additional context for request

/cc @brendandburns

[brendandburns]

/assign @nikhita

[brendandburns]

@nikhita any chance you can look at this when you have time?

Thanks!

[nikhita]

Since this would be under SIG API Machinery, we'll need a +1 from one of the leads.

/assign @fedebongio
for approval

[n4j]

👀

[dims]

@brendandburns the folks doing krator + krustlet ( https://github.com/krator-rs/krator / https://github.com/deislabs/krustlet ) will join in this effort?

cc @thomastaylor312

[sladyn98]

I am super excited for this. Made my first PR to krustlet and looking to make more : )

[brendandburns]

@dims I will certainly ask them to see if there is interest/time in contributing. Definitely welcome as many people as possible to help with it.

[thomastaylor312]

Any reason we are making an entirely different client than the existing one? Or am I misreading this? kube-rs is widely used among us Rustaceans and also uses the already generated k8s-openapi crate

[technosophos]

I'm curious about the same thing @thomastaylor312 is concerned with. The Kube-rs and k8s-openapi exist already. k8s-openapi is maintained and kept up-to-date with Kubernetes. Kube-rs is idiomatic and field-tested, and the maintainers are active, friendly, and flexible. We've written operators, clients, and (of course) Krustlet using kube-rs & k8s-openapi, and it has been a great tool.

Starting a new "from scratch" project is going to confuse the ecosystem, compete where no competition seems warranted, and introduce an "official" repo that is already years behind the existing tooling.

So before proceeding here, I would like to suggest that someone provide a clear and compelling reason why we should go this route rather than (a) inviting Kube-rs abd k8s-openapi to be the Kubernetes Rust client tools, or (b) simply recommending the existing Rust implementations and not having an "official" one.

[bacongobbler]

Tacking onto other comments from krustlet maintainers... @clux has been a fantastic maintainer of the kube-rs project. The project has been incredibly responsive and he has been maintaining that crate for a number of months. There are also several sub-crates of the kube-rs project including kube-derive (derive macros for CustomResourceDefinitions) and kube-runtime. Several projects including krustlet, kdash, and plugins such as kubectl view-allocations have been using kube-rs for a while now.

The documentation, support, and overall community is great, it's passes as a silver client (watch APIs are supported), and quite a few examples are readily available.

I'm also curious why create a new project instead of recommending one built by the community. Or better yet, why not provide additional support for the project?

[alberthuang24]

k8s-openapi is maintained and kept up-to-date with Kubernetes

The k8s-openapi doesn't seem to be maintained by kubernetes? @technosophos

[thomastaylor312]

@HongjiangHuang It isn't maintained by Kubernetes, but it is maintained and kept up to date with the latest API versions. I think @technosophos was suggesting that k8s-openapi could also be a good candidate for adoption over into Kubernetes