[rustyk8s] Hi and whats the plan?

[Justin Cormack]

On Sat, 9 Feb 2019 at 01:58, Robert Collins <robertc at robertcollins.net> wrote:
>
> Hi, I'm one of those people; I've been collaborating with Angus Lees
> (cc'd) on kubernetes-rs for a while now, though as both of us had very
> rare time slices it hadn't moved very far in that time (and most of my
> contributions had been design discussions for the same time
> reason).... I'm planning on putting a good solid spike in starting
> around a week from now (got a 2000km road trip to do beforehand).
>
> https://github.com/anguslees/kubernetes-rs
>
> The broad goals of that repo are to create a crate that permits other
> crates that:
>  - implement controllers in as little as a few lambdas
>  - implement ops-scripting problems pithily
>  - export 3rd party CRD datatypes for use by others (e.g.
> kubernetes-rs + some-crd-crate + some other crate that uses the crd).
>  - implement API servers (for k8s api extension by proxied requests)
>
> With this crate itself having the following attributes:
>  -type safe modelling of the API (e.g. Enums rather than strings that
> may-or-may-not-be-correct; and the ability to write get compiler
> errors on match branches missing arms).
>  -native async interface
>  -unstructured handling as well (safety valve for unknown types)
>  -avoid large redundant code generation
>    (e.g. provide Derive implementations rather than running a codegen
> which outputs parallel modules)
>
> There's a good representative core there, but we aren't quite happy
> with the ergonomics of the layers - once we are expanding out into
> full API coverage, and implementing an actual API server itself
> shouldn't have any major speed bumps.

This definitely looks like a good set of requirements and starting point.
Look forward to seeing the next steps.

> Personally I speculate that the go constraints have deeply distorted
> the API server - CSP is great for creating correct code, but not great
> for being able to control that code in a very precise way across the
> entire system - https://github.com/kubernetes/kubernetes/issues/12208
> for instance is *still* open, and its lack drives many other bugs such
> as the ones around kubelet qps <-> apiserver (which shows up in e.g.
> https://github.com/kubernetes/kubernetes/issues/23349)

It doesn't surprise me that no one wants to tackle these issues with the
existing code base and they just remain open. And agree, resource control
in Go is not how the system and its libraries were designed.