[rustyk8s] Hi and whats the plan?

[Robert Collins]

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.

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)

So I'd love to have an apiserver that is compact and lean and see what
we can do with it.

-Rob

On Fri, 8 Feb 2019 at 12:21, Justin Cormack
<justin at specialbusservice.com> wrote:
>
> Hi,
>
> Its all pretty free form! We have a few people who should chime in
> shortly and talk about their experiences with
> writing Kubernetes client APIs in Rust, and working with the types and
> so on, which I think is generally helpful,
> and another who hacked together a bit of a rough prototype as an
> experiment, which I think will generally be
> helpful.
>
> Overall we have a mix of Rust beginners and experts and also people
> with varying depth on the k8s APIs, so people
> may want to collaborate, but I agree we definitely don't all want to
> sit down on day one and try and work on one
> thing, just see what you can get to work and ask for help and advice,
> but ideally in the open so others can look and
> contribute.
>
> Justin
>
> On Thu, 7 Feb 2019 at 17:59, Darren Shepherd <darren at rancher.com> wrote:
> >
> > I've missed any discussion on this topic might have happened so all I know is based on the https://www.cloudatomiclab.com/rustyk8s/ blog.  Is the purpose of rustyk8s to hack on a shared implementation or a place where people can share thoughts on their own k8s implementation in rust they are hacking on? Asking because of this tweet https://twitter.com/justincormack/status/1067185866001575936 makes it seem like a competition (which I'm all for).
> >
> >
> > Darren
> >
> > _______________________________________________
> > rustyk8s mailing list
> > rustyk8s at lists.opendev.org
> > http://lists.opendev.org/cgi-bin/mailman/listinfo/rustyk8s
>
> _______________________________________________
> rustyk8s mailing list
> rustyk8s at lists.opendev.org
> http://lists.opendev.org/cgi-bin/mailman/listinfo/rustyk8s