Ready? Let's take flight. Too many charts, too many files, templated traps for a thousand miles,
curly braces, values gone wild, Kubernetes with a loaded smile, then Yoke walks in with a
cleaner plan. Write real code, let the package stand. Wasm kicks in the cluster lights. Flights
go up on a Friday night, Copilot test it, ship it clean. Less mystery in the
machine, no more guessing what broke this time. David's got it on the line. Flight,
no turning back. Wasm on the runway? Thunder on the track from Helmborn
goes to a cleaner road. David's here and we're talking Yoke. Sign
the module, jig the hash. Don't let the wild scripts Hello,
and welcome back to the Rawkode Academy. This is yet another episode of Rawkode Live, the
show where we take a look at the latest and greatest open source projects powering our
cloud native architectures and making our Kubernetes lives a little bit easier. And today is no
exception. We're taking a look at a project called Yoke. And I am joined by David
from a nice sunny location. Hey, man. How is it? How's it going? It's going well.
It's going well. Glad to be here. I I had to, you know, the aviation themed
project had to have a sky in the background. So Exactly. We need to put an
Easter egg where people can count any planes going by, and we'll give them some, I
don't know, a mug. A mug. That's a good price. Alright. Back on it's
lovely to meet you. Thank you for taking time out of your day to join me
and to share your your project with us all. So before we get into what Yoke
is, could you just take a few minutes to tell us a little bit more about
you? Sure. Sure. Feels like a job interview. Yeah. No. So I am
my name is David, and I am the original author and lead maintainer of the Yoke
Project. I I like to say I've been doing software for just a
little bit more than ten years now, and my background has always been, as a back
end software developer. And I went through, you know, the the the the early days of
my career was all about, you know, mean stack, JavaScript, kind of, go with the flow,
no types, don't you know, just do everything as quickly as possible, and we'll figure it
out later. And as my career grew, I was always like, oh, like, we we really
do need these things, and it's really awesome, you know, building software when you have the
right tools. And then a couple years back, I switched into platform engineering, and it was
like I jumped back into 2015. And so yeah. And
so I'm just making my little effort at at, you know, changing that a little bit.
And so here we are today. So what what what powered what drove the switch
from your main stack onto platform engineering then? Oh, I I ended
up doing I I worked at CircleCI for a couple years, so I moved closer to
to just working on CI systems. I was doing, like, security engineering and CI related systems,
and then and then I just wanted a change. So I jumped I had, one of
my friends who became a, a platform engineer here in Canada, who was, like, director of
DevOps a company. And I'd worked with them multiple times before, and I just thought, yeah,
I could do a different challenge, and, it's been interesting. So you jumped over to the
platform engineer and save. You felt like you went back in time. Everything was on fire
and looking like shit, and you thought, You know? Yeah. Yeah. Well, I thought I thought,
like, I've seen this problem before, right, which is I mean, I I hadn't seen it
exactly in this in this way, but, you know, it just felt like we're plugging things
together. We're hacking things. You know, we're we're bashing script together, and then we're we're templating
variables in, and everything's producing YAML, but YAML is just JSON. And so whenever I hear
somebody say that they're a YAML engineer, in my mind, I just translate that to I'm
a JavaScript object notation engineer, which is just like a weaker form of JavaScript engineer. Anyways,
no no shade. No shade at anyone. We all do, you know, the best we can
and the god the lord's work. But but, yeah, I just felt like if if things
could be typed, we could just build so much more resilience into our systems and make
them so much more fun to work with. I mean, I I I could agree more.
So with that, why don't you tell us a little bit about Yoke and the project
we're gonna show people today? I'm sorry. Can you just repeat the question? You cut off
just a little bit. Sorry. Hopefully, that's not my connection. But yeah. It's a cross Atlantic
call. You know? Yeah. I was just asking, you know, with everything you've just shared then,
you're gonna show us an amazing project, or we're gonna take a look at an amazing
project called Yoke. Can you tell us a little bit about it, the problem I was
trying to solve, and and why you even had this idea and started it in the
first place? Yeah. Yeah. So the the the
project in the platform engineering space that I've I've had to work with even before I
was a platform engineer and that always gave me, you know, nightmares was was Helm.
And writing Go templates and just, like, trying to figure out the indentation that
you need for a specific block, especially when you're not e now today, that's changed myself
at least. Like, back then I wasn't super familiar with all the Kubernetes objects and just
having to template things that you don't even know what they're supposed to look like was
was just terrible. And nowadays it's it's a bit better and I'm more familiar and familiarity,
you know, breeds, you know, the illusion of comfort. But the but
I just always felt like we're, you know, paddling up river when using Helm. And my
idea was always would just wish I could just write a program that could just produce
the Kubernetes resources that I want, and and I didn't understand why I couldn't just do
that instead of templating the root the resources. And so at some point, just thought,
yeah, we have to we have to do this. And the eureka moment came when I
was like, well, running code is hard and porting code is hard and doing all this
kind of stuff and securing code is hard. But when I realized I could just do
it with WebAssembly, then that was just kind of like the light and, and I ran
with that idea and then eventually Yoke was born. Awesome. I mean, you're saying all the
right words for me. I like types, I like WebAssembly, and I like Kubernetes. I do
not like Helm, and I do not like YAML. So all the favorite words coming out
at once. What I would say is necessity always powers innovation. Right? I'm sure there's like
a proper way to say that. That's the famous quote, but that's just the way I
remember it. And I think say spite powers innovation. I mean,
yeah. Definitely. Right? We we see these things that frustrate us and, you know, I've been
in the Kubernetes space for a long time, so have a lot of my viewers. And
I don't think anyone likes Helm. We're just in a position where it has it it
it's solved a problem at the time and now we seem to be stuck with this
thing because everybody has a Helm chart for their application. But Yeah. These things are just
big balls of mud as far as I'm concerned. Everything, a line of YAML gets templated,
everything becomes an option and, you know, we're not even gonna talk about Helm hooks. Right?
And let's even not mention Helm Tiller. Right? There's been a lot of mistaken paths that
have gotten us to where we are today, but I do generally feel that we need
something better moving forward and the community hasn't really got that option yet. And
I guess the question to you would be, how do you see overcoming this hurdle of
the status quo within Kubernetes and pushing people or encouraging people to adopt what is essentially
a better tool? Yeah. And I I think what's interesting is that there there are already
a lot of better tools. Right? So, I mean, one of the the the
closest would be Timoni. Right? The the CUE-based package manager. We
already have a better helm in in in that one. Right? So it is it is
hard. I just think that where Yoke is slightly
different than the other tools is that it's not it it it changes the viewpoint on
on and how we interact with Kubernetes. Right? It's no longer a configuration issue. Right?
It's not about, like, how do we configure our resources or what configuration language should I
be using or what configuration format should I be using. Instead, it shifts it more to
like a a an programmatic space. And so it's a it's a logic problem. And that's
why Helm is is is is so difficult. Right? It's because you're writing YAML essentially, but
then you're templating parts of it out, which is saying, like, I'm gonna put a conditional
in or I'm gonna put a loop here or I'm gonna do a loop and a
conditional or actually I need to build some variables and I need to to YAML them
and from YAML them or do whatever kind of anyways, I'm I'm going off. The the
point is is that the that it's actually a logic issue, right, that that we wanna
solve. What we wanna do is express logic, and that's where Helms break down breaks down.
Because as a viewing engine, that's fine, I guess, if you're into that. But and
where Yoke is different than than Q or different than JSONets or different than, you
know, all these other ones is that we're not trying to invent a new language. I'm
just trying to make a path forward. So say, hey, you can express this with code
and you can have all the advantages and disadvantages that come with that approach,
but you're free to choose it. And I just other than maybe, KCD, the
the this would be, like, the only option, I think, in the ecosystem that allows you
to do the code first approach. So pushing that forward. Oh, and for adoption. Yeah.
I don't know. I hope I hope that we can. There there there are ideas within
Yoke that we can explore later. One of the things being that it is code, so
we can run Helm charts with Yoke. There's a bridge. It's a Go specific
bridge, but there is a bridge, and maybe we can see that later. Alright. Awesome. Yeah.
I think we'll we'll get hands on now. But I I just touch on on one
more thing as part of that conversation is that, you know,Timoni is a great project. I
think people struggle with Q. It's very academic. It's difficult for them to learn. I am
definitely I I love Q. I use Q. I write loads of Q projects. But every
time I get one of those projects to someone else, they're like like, that's too hard.
I'm not doing it. Go is certainly something that people are very familiar with within the
Kubernetes community. So I can see the appeal of a tool like Yoke for enabling them
just to use the tool chain that they already have. Right? And and be instantly on
ramp and good at what they have to do, which is fantastic. And what I like
about it is that it's one of my arguments when I make this pitch is that
it's also a more translatable skill. So if you don't know q and you don't know
go, I mean, they're both great things to learn. The more things you learn, more power
to you. But if you learn a little bit of go and able to to be
able to write your packages, well, now, you know, a little bit more Go and you
can do a little bit more things even outside of writing, you know, Yoke packages. You
could Yeah. Maybe hook into writing a server or doing something else, you know. So it's
just a skill that is is good to have, right, if you're if you're interested in
programming. Yeah. Alright. One one last thing, because it's kinda slightly pertinent.
As regards to like alternatives to Helm, customize is one that I always like to kinda
bring up as a thought experiment because it's baked right in to cube control. And yet,
I still never see any adoption of it in the wild. I'm curious of whether you've
played with customize and why do you think people aren't picking that up even though it's
right there? Well, for me, it just doesn't scratch oh, I bet the
reason I'm not picking it up, it won't be the same reason that other people aren't
picking it up. For me, it just doesn't scratch that type safety itch. Right? Mhmm. The
idea that I wanna express my things logically and then, like, build upon them. If you
know your your paths and how you wanna patch things, then then then that's good. And
I guess that's a that's a system of overlays a bit similar to, I guess, how
Helm does its merges. But at the end of the day, I think that it doesn't
help me I, like, break out of what I would call YAML soup. You know? And
so I think it might customize is probably, like, a great the biggest advantage that it
has in my mind is that it's more flexible in some ways when dealing with, like,
resources because you can just be like, know exactly what I wanna patch, and I can
I can go there? And if the Helm charts or even the Yoke flight doesn't expose the
the knobs for you to do that, then it's hard to to to to
to target those things. And I think Customize does great there. I just wish that Customize
was more adaptable to more things or more pluggable into other systems instead of trying to
be its own thing when it doesn't yeah. I don't have as much experience to
talk about with customized to speak on it as much as I am. So I'll speak
before. Alright. Awesome. Let's just get my screen share.
Let's do this. So as accustomed, we're pretty much all Rawkode Live.
I have an empty directory with absolutely nothing going on at the moment. What
we're gonna do is we could go install, but there is a homebrew. Right?
Yep. So I can brew install Yoke. Well, let's get the Yoke CLI available and then
we'll kick things off from there. Yeah.
My connection is not too bad today. That's good. Alright. There are a lot of
aeronautical rarefaces. I've I've had some people on Reddit make
a bit of fun of me because of the of the aeronautical theme. But do you
do you understand the the the analogy to to helm? To
helm? Well, Helm is Helm is a is a Yoke is a a plane. Right? Yeah.
Yeah. Yoke is just a steering tray, a stick of a plane. Yeah. And I just
I when I started writing the project is I don't I don't feel I don't like
flights. I'm a bit anxious. I'm an anxious flyer. And I just needed to take my
mind off. And I knew I had this, like, idea to play with Wasm and Kubernetes
package management, and I just did it on the plane without Wi Fi and nothing. Just
just grilled through it, and and then that kinda became the theme. Hey, you can vlog
that source as long as you want. I'm here for it. I am happy with Takeoff,
Descent, Mayday, Black Box, Turbulence, Soul, etcetera. Like, I think it's fun. Right? And if we
don't enjoy what we're doing, then why are we even doing it? So alright. So why
don't you give me the the Gedi tour. Right? I have a Yoke CLI. I'm gonna
assume in fact, I'm not gonna assume. I know if I run Yoke takeoff, we're we're
gonna have a problem. So it tells me I need a release. Let's just call this
rocket. We don't have a flight path. Again, more of these aeronautical terms. So Yeah. I'm
assuming we need to write ourselves a little bit of code. Yeah. So the
what's interesting is on a really really abstract level, what we need is a Wasm module.
That's what we need. Right? So what however you wanna produce a Wasm module, I mean,
best way is to write some code obviously. And I and I think that if you
wanna write it in Go, if you wanna write it in Rust, if you wanna if
you wanna write it in WAT and then use a WASM compiler, it doesn't really matter.
You As long as we produce a WASM module. So for me, the best approach is
to write a Go program and compile it to WASM then we can just import the
types that we want directly from the Kubernetes project. That's how we What
I will do is just take the there are documentation to everything here. Right? You don't
need to do it as a hard rate to the people watching. So please feel free
to go check out the the docs on the website. And let's talk about
your adoption of of of WASM. You could have just done this and go. Right? And
Well, that that would work fine. Right? Like, why why did you feel the need to
kinda push it to be this multi language control plane for for Kubernetes? Well, I mean,
if you do it in Go, then how does that work? Right? In the sense that
the problem is is that if if I wanna make a program that can run packages,
say that I'm home, let's say I'm home, well, I still need to run a package
and a package is in this term it's a zip of of Go templates. Right? If
I'm a a code based package manager like Yoke is, then I wanna run some
code. And so I get into all these issues where it becomes like, okay, well Yoke
actually, I run version, I'm bundled with like the Go tool chain one dot something or
I use your Go tool chain and so now I need to go to be installed
on your machine and my machine and I'm doing a bunch of exec ing. I don't
know. And then also, if you're running code, code is super dangerous. Right? Like I could,
you know, read all of your dot AWS credentials and send them to a backdoor that
could be the program that I write, you know. I could do a ton of things
like to read your environment variables. So running code is especially arbitrary code
that like maybe somebody's sharing a package with you and you wanna deploy, you know, their
Redis package that you wanna install. Running arbitrary code is is is scary. And
so, when you use Wasm, you're kind of sidestepping all of that. You're just saying like,
here's a binary. That by the way, you don't need to make sure matches your architecture
or anything like that, whether on ARM or AMD or or whatnot. You just say this
is WebAssembly. And when you run WebAssembly, runs in a sandbox. So it doesn't have access
to your file system, doesn't have access to the network, doesn't have access to your environment
variables. It's just a little computer, right, that you're running embedded inside of Yoke. And
so you get to build and run logic, but you don't actually have access to to
most dangerous things. Portable and universal and and tons of languages can target it. So for
me, other than a lot of people aren't familiar with WebAssembly, it was just like a
no brainer. Sweet. Alright. Let's try some gold
then. So what
I mean, I could do this well, we'll do let's just look at YAML strings. Right?
This is the first example from the the Yoke documentation. So we could just import
format and then all we need is a main function. I don't write a lot of
Go. Yeah. It's funk main. Yeah. Funk. Well, was writing n main. I'm
a Rust developer these days. I know enough goes probably still to be dangerous and that
is about it. So You you could you could write this in Rust if you're more
comfortable. I would be less comfortable, but you could be more comfortable and that could be
the magic of it. But let's let's keep going if you want. Well, let let's let's
do the gold one first. Alright? And then we'll switch to to Rust. Yeah. I mean,
we could do this multiple way. This is even Rust native languages now, which I always
think is really interesting concept as well. So WebAssembly, sorry, native languages.
So I used to do a lot of stuff. It was like the Fermion spin project.
And just seeing that whole WebAssembly thing coming along was always very cool. But I I
will try and remember how to write. Go. So let's just do let's
see. We could see our deployment. Yeah. Well, while
you're typing a little bit of context for for anyone listening. If you wanna define what
a package is, it's just a program that maybe reads inputs on standard in or from
flags and then outputs resources as JSON or YAML or
arrays of JSON and YAML and that's it. There we go. So yeah, here you go.
You have you wrote a deployment in in straight YAML, and you're printing it. Yeah. I
just told you this from your documentation instead of me trying to butcher my way through
right in a Go program. Sure. I love it. Alright. So I
could do Go run. I mean, they called it Mendelco. Right? Yeah. It's just best
out. Yeah. I'm on. Right. So this is what? This is a a Yoke flight? Yeah.
It's a program that complies with the rules. It outputs resources, so it's a valid program
for Yoke. Mhmm. So would this work with Yoke,
takeoff,Rawkode I have to compile it to WASM binary first. Right? You're not gonna Yes. I
I don't I can't I don't have a Yoke doesn't have a Go tool chain, so
it doesn't have any tool chain other than it embeds Wazero. Shout out to the folks
who made Wazero, a zero dependency runtime for Wazim in Go. But, yeah.
So if you write Go as Wazi preview one, go arch Wazim, you can build out
your example dot Wazim and you can compile your main dot go. Okay. I'm gonna call
this go just in case we end up with multiple wasms. Yeah. Alright. I have a
go wasm. Yeah. So if you do Yoke, takeoff, you can give it a
name like foo or whatever whatever you'd like. There are a lot of flags. Yeah.
I'll just take a look at some of the examples. So we just give the release
a name, not too dissimilar from the way that Helm operates, and then we can point
that to the to WASM artifact, which you also support gzipped WASM artifact. Sure.
Remote flights. Do you support WASM wrapped in OCI? Yes. I do. Sweet. That's pretty
cool. Yep. Yeah. So you can and but you have to use the Yoke CLI to
push them. It compiles like, turns it into a single image static layer g zipped with
like an image package and you can push that to OCI registries and and Absolutely, we
do. Very nice. Alright. What about this one here? This
this is general resources script as an actually Wasm. Right? I I love this because you
can see there's a a typo in the in the name over there, my release. Anyways,
yeah. So there's there's there's a there's a there's a bit of a lie that I
also that I don't say at first when trying to like hammer in the initial principles
of Yoke because Yoke wants to deploy packages and packages generally are made from an asset
like a a WASM module. But, you know, a lot of languages
don't necessarily support, you know, WASM or easily support WASM. And
a lot of things are also shared as like straight YAML documents. Right? And so I
sometimes still want to manage external sources of of YAML, whether it's from an arbitrary program
or from a file, and package it and and treat it as a release. And so
what you're seeing right there is that if you don't give the second argument, if you
don't give the Wasm module and you pipe in data, if you pipe in standard in,
then it'll just say, okay, I'll use this as the computed source. And so here, if
you say generate resources dot s h, suppose that it, you know, creates a a YAML
document or a JSON document and you pipe that in with a release name, then Yoke
will deploy that for you. So you could actually, in your example, do your go run
and then pipe that into Yoke takeoff with a release name and it'll it'll
deploy that without you having to go through the Wasm step. The only difference is that
now you're you're running an arbitrary program on your machine instead of running a Wasm module
that's sandboxed and shareable and all this kind of stuff. Alright. I'm going rogue already, but
I just wanna explore a few different things here. So I firstly, I just I stuck
at the deployment and try deployment dot yaml so that I could do a queue import.
So now we actually have a queue file for a Kubernetes deployment. So in theory, I
could run a queue export and put this through Yoke takeoff, which we'll do shortly. Let's
focus at least do it in the first demo without me going too crazy on you.
Sure. And let's do the takeoff and we'll call this go because this is the go
example and then this just takes the go dot wasm like so. So when there is
that second parameter, which is your your flight flight path, this is going to execute wasn
workloads. However, we could skip that use standard input and then we'll see an example of
that shortly. So Sure. Okay. I successfully took
off Go. What does that mean? So we created a revision. So if you
say Yoke black box or its alias is Yoke inspect. So
you've created a release called go in the default namespace and it has one revision. If
you say revision one oh, yeah, go. You did you did the right thing. So now
you see that we have one revision. And, yeah, the revision one is basically this resource
that we created. Well, that that was a test, by the way. Like, I I always
feel like the best developer experience is when I can be successful with intuition rather than
informed decisions. Intuitively, I just kinda worked my way through to getting what was actually
deployed to this cluster. So I think you're you're getting a tech on that DX path
there because that worked the way I expected it to without me consulting the documentation, which
is good. Nice. So, yeah, just because I cannot interrupt you here.
Black box inspect shows us all of our releases. We got a namespace here. We can
then take that further. We can take a look at the actual flight path that was
deployed or the release that was deployed and we can see SHA. And then, I'm assuming
if I run kubectl get pods, we can actually see that my application is
well, in this case, it's just NGINX, but NGINX is deployed to my default namespace. Yeah.
Nice. That's Alright. So the question then is let's
change this to replicas one. So, we've made a modification to my goal
binary. I am gonna do a goal build again. And before
I do this, if I run this again, we're gonna get the same release of
Go with revision two and is that automatically gonna apply that to my cluster? Yeah.
So when you run Yoke takeoff, it it it applies to the cluster. If you wanted,
you could do dash standard out, which would preview it on standard out without applying it.
I use the Go standard library flags, so you actually have to it before the positional
arguments. So you'd have to put dash standard out right after takeoff. It's it's a really
quirky thing of the of the Go standard library and I kinda just wanted to stick
to the standard library instead of using Cobra, which is maybe not the best UX for
my users, but just a a little thing that I I like to see. And
Mhmm. So now you've got this. You intuitively this is the non intuitive part of the
CLI. You intuitively did Yoke, Black Box, Go, one before.
You could do two and then do space one and it'll compare them. Yeah.
Sweet. Yeah. So you can see what actually changed. Very nice. Yeah.
Alright. And I'll just assume we now have one replica, which we do. So
question then. The Shah is the generated Yamo
artifact rather than anything to do with the Wasm. Correct? So, like, if I decide Opposite.
It's the it's the Wasm. Oh, really? Yeah. Yeah. It's it's kind of
the the idea a little bit is to track the
Wasm module that you're using because the flight name, right, right now you're saying that you're
using the local file go dot wasm. You built two different go dot wasms. Right? So
so you it for you, this is just a way for you to visually know that
this is not the same go.wasm that you used. And this can have this
can have implications, you know, with like digest pinning and stuff like that. There are concepts
of if you have right now, you're not you you're not using semantic versioning, but if
you said like, hey, go v 1.wasm underscore v 1.wasm or whatever, it wouldn't realize that
if it can detect semantic versioning to an extent. And then if you try and change
it, it'll say like, hey, like you're you're maybe attacking the cluster. And now on the
local file system, this doesn't this doesn't make a lot a ton sense, but if you're
using a WASM module served in a GitHub release or over over or or even OCI,
if you don't expect it to change because you're using some semantic version, but it does
change underneath you, it'll it'll complain. So it's a bit of a security feature. I expect
the YAML to change because or the resources to change because you might be configuring them
differently, your programs might, you know, take inputs, and so I'm not really tracking the YAML
per se in terms of SHAZ, I'm tracking the the source. Okay. Yeah. Alright.
Let's make this more interesting. I have now copied your typed goal approach
from the documentation, which is doing something very similar. So if we just take, you know,
thirty seconds to go through this, we have release and namespace. So
this is you mentioned inputs. I'm assuming these are inputs. I'm going to assume again.
If I want to, can I make replicas an input as well? Sure. Where I just
say that this is let's just say we default to to one. Would that be appropriate
here? Or Sure. It would be just something else? That that would be fine. Yeah. Okay.
So you can tell me how we turn this into a real input shortly. Right? But
let's set to And and if you want, just when you said the things you assumed
those were inputs, there's actually some nice little comments that you pasted in from the from
the example. So these ones, because they use the flight package, they're kind of special in
terms of of when you use it. Kind of how in your in in Helm, you'll
have, like, dot release release dot release namespace and all of that stuff. This is just
it's just the the arguments. So when you say Yoke takeoff and you give it a
name, before that would have been Go, so it's the Go release and the namespace is
the namespace you're deploying to. So anyways, yes. Alright. So
then we are using create deployment, create services or helpers that you've got for creating
or scaffolding these Kubernetes resources. We can scroll down and we can see the deployment is
here, return an attribute on deployment. Nice and simple. Let's see. Replicas is coming from
config replicas, which I think I hooked up low up, which I think I hooked up
above. But although as the it's right now, it's hardcore just to one, but we can
take a look at that in a second. And then we have the server. Overly complicated
in this example. I could've just dumped those straight into the main. I decided to break
it out just to make to show people that you could, you know, make your own
functions. But it doesn't really help readability in this case, but, you know, here you go.
I know. But when I'm doing things as code, right, I want the conveniences of having
functions and multiple packages and abstractions Yeah. That me and my platform team decide that this
is how we're going to do things. Right? So I I I like the fact that
this is not just a main that is just wrapping, you know, at v one deployment,
etcetera, and returning whatever. So I'm here for it. What I wanna know now is I'm
assuming there's some sort of, can I use like flight argument or something? Like, how do
we or I've they're just standard go at this point. Right? Am I just It's it's
all just standard go. You could read you could read from standard in or you could
you could read an argument, like a flag argument. Yeah. Yeah. So that would just be,
like, using Viper or something or even just Or or flag the flag package. Yeah. Or
you could even just read in the first argument. Yeah. You could do anything that you
would do in a normal Go program. Alright. I'm gonna keep it at one right now
because I wanna I wanna deploy this. So let's pull up that Go build command again.
And You might need to make this a module. Demo.
I'm actually gonna pop off for two, three minutes, and I'll let
you get just play, and when I get back, we'll see where you got. Yeah. I'm
gonna play with a queue demo as well. So you gotta do what you gotta do,
and I will work out how to deal with the ghost site. Okay. And I'll I'll
I'll be excited to see where you get to. I'll be back in five or maybe
less. Alright. Why can't I not go there we go.
Go my tidy, then all my dependencies. And
then we'll do the go build. Alright.
Cannot use a replica's variable of type int as an enter to do. Fine
then. Fussy pants. I've seen something at the bottom and no. We're not doing the
int string, though. You guys see where my goal is gonna let me down. Oh,
mad heaven. Alright. So let's
just there was or it was an Insta journal, right, when I copied and pasted it
from the documentation. Let me just double check that. I don't think I did anything there
that was different. Yeah. It was an integer, but the difference is the
integer was defined somewhere else. Because when I changed this, this was just set to two.
So now it's probably gonna be more than I'm not using replicas. Yep. So
let's just remove that because I don't care about that right now, and I'd rather just
get this working. Cool. So with this
now, we should be able to do Yoke, takeoff. We'll still call this go,
and we're still running go dot plasm. Only I did see there was another command rig.
It was Yoke,Diff. I don't know. Was it turbulence? Drift?
No. There was a death. I thought I seen a death. Drift.
What is drift turbulence? Let's see. Get
the death between desired state of release foo and the state in the cluster. Interesting.
So that feels like it should be what I want, but then I'm not it doesn't
seem to take a second parameter. It just seems to take a release. So if I
do turbulence go, it says there's no turbulence detected. So this must
be something to do with takeoff, perhaps having those extra flags on it. So let's take
a look at that. Because also, one of the other things I did notice is
when we did black box or inspect is that and we say, oh,
we say go is that we can have a current. Right? So there seems to be
this idea of progression, rollout, whatever you wanna call it. So I am curious if
I can stage my new takeoff where it does register
it, but we may be yeah. There is a dry. What else
do we have? Alright.
Let's see. Would it dry, go and go to Azam? So
we had a dry run. So if I do black box now on go oh,
it's not there. So it just did a dry run. It didn't actually stage anything. So
we need to ask David about that when he comes back. Let's just get the deploy
going now then, and then I'll understand that whole progression thing when he's available to chat
to me. So now our Wasm ran. We
have our version three. Actually, nothing should have changed. So I don't need to run a
def rate. We just switched from string templates to goal values.
And I have questions. So let's wait. While we wait
for David to come back, let's try the q one. So I imported that deployment dot
yaml to a deployment.q because I like q. And we now know that if we do
a q we need to add a package,
and we'll just call this q. There we go.
Then we get the JSON for this. So I think I can do Yoke
take off and call this queue. What I want to do is make sure that we're
not blasting away any existing workloads. Although that would cause turbulence, wouldn't it? Should we start
just exploding and breaking things? Yeah. I think we shall. Let's
do one, but this time we're gonna blow this away and have the wrong
application. In fact, we'll keep it NGINX, but we'll change the version too.
I don't know. I I don't know why I can do that. I'm back. Oh, thank
fuck. Okay. I'll I'll fill you in a second of what I'm doing. Right? But I'm
I'm purposely trying to cause turbulence. So I'm gonna do a takeoff Love it. Here. It's
a Woo. I'm so glad. Okay. I'm gonna back up now so you can see what
the hell I've been doing. Deployed in fact, I'll scroll up so
you can see my thought process. So okay.
So I knew that it was a def command because I I it flashed me when
we were running help commands earlier. So I was like, okay, drift is turbulence and that
shows us when things are are are changing. So I ran turbulence on Go even though
I'd modified to go wasm binary. I wasn't really sure how to detect the turbulence. So
I started thinking, okay, well, we need to cause some sort of drift to some degree
first. So I was wondering then if we can do progressive roll outs. So I ran
black box, black box go and then obviously we have current. So I was like, okay,
can I deploy a new takeoff of three but it's not current? So I then started
looking at the help. Found dry run. It didn't do what I wanted, I said fuck
it. Yep. Let's just deploy. So yeah. So what would Drift would be, it said that
you deploy something. Right? You the your whatever version you're at is great. I imagine you're
you're still just tweaking replicas. Right? Oh, I see you have two resources now. Yeah. Drift
would be if somebody if a rogue platform engineer went into your cluster
with kubectl and edited the deployment for you. And they and so it's no longer Drift
is that it's no longer it's now conflict the the cluster state is now conflicting
with the desired package state. So if you deployed it with two replicas
and then I come along into your cluster with my kubectl and my two godly permissions
and I start editing your deployment, now there's drift because
cluster state doesn't match the package state. And then you can use a turbulence command to
bring it back to the the desired state. Yeah. So it's it's kinda controller style Drift.
Right? As if we were doing some sort of get ops pattern and and things change
in the cluster, etcetera. Yeah. So I kinda was leaning down that path and then decide,
okay, well, I'm gonna cause some drift through malicious action. So I took a look at
my queue export, fixed up package name, and then realized this is the same deployment that
we used with Go. And I decided, right, well, let's just change the image name. And
then I take off my queue because what that should now show me is that we
run Black box queue, black box queue. This one is fine. But now this go one
should have turbulence because I just blew over its deployment completely. So turbulence
go. So Oh, I can't spell turbulence. I'm just gonna do Yeah.
Oh, no. No. I I changed the image. So I'm curious then. So I wonder, just
do you keep still get pods? So
they're different. Right? Yoke will not let you have two releases, two different
releases control the same resources. So if you were to create, you
know, a deployment called example through your queue release and you were to create an example
called oh, yeah. The deployment called example through your go release, the second one would conflict
and it would it would break. It would well, it would do its best to not
do it. So you're better not using Yoke to try and create your drift.
It's not impossible. Right? You could have race conditions if you had like two users do
it at exactly the same time. But technically, it's not easy to do with Yoke. So
if you wanna create Drift, I would, yeah, I would go into it with k nines
or cube cuddle, create the Drift that you want, and then ask the the specific release
name if there's Drift on it. Yeah. So what I hadn't appreciated there
is when we switched from the string implementation to the go type implementation is that we
then started to use the release name as part of the the resource. So my
queue actually overwrote something or actually created a new deployment because we changed the name Exactly.
Of the thing. Okay. So we can do a queue control at a deployment. It's just
there's a I can't remember that. Here, go. Okay. Edit,
deploy, go. Now I'm sweating because I I haven't run this command in in
at least six months. But there's tests, so I mean, it should work. Yeah.
We'll see. Yeah. So if we say turbulence, Okay.
Yeah. That so I modified the end cluster. It popped up in zed because that's what
I use as my editor. I'm only sharing my terminal because my screen sharing thing has
been very weird today, but we have Drift. So Mhmm. We could just take off again,
right, and reconcile that. You know, you can write you I mean, you could, but you
could do fix the the fix flag on if you do Yoke Drift dash help. Well,
as I said, fix has to be before. And
it's fixed. So this is very CLI driven manual. I mean, is there an end cluster
operator for Yoke to handle this for me? Yes, there is. Sweet. Tell me about that.
So backing up a little bit before I answer your question directly. Mhmm. In
the same way that I'm trying to be agnostic as much as possible with regards to,
like, which language you're using and all those kind of things, I I'm trying to not
make Yoke a thing that tells you how you'd need to run your clusters. So
what you're playing with right now is core Yoke, like the core CLI, and that's just
like the core, you know, Helm style client side package manager. But the project also tries
to enable as many ways as possible to to to work with code in your clusters.
So there's an ArgoCD plugin so that ArgoCD can use these packages. And there's
a server side controller called the air traffic controller, again, with the the the aviation theme.
And the air traffic controller, what it does is that it lets you deploy them as
static resources. So you would have a generic flight resource and then you could fill out,
you know, my input is this, my WASM module is this, and and it would work
that way. And the air traffic controller, what it lets you do is also create meta
types, kind of like how Crow lets you do RGDs, you're familiar with Crow. You can
create higher level attractions that are kind of like wrappers over CRDs.
They're called airways because Yoke. So with the air traffic controller, can declare airways and then
you can build your own custom resource and bind it to a WASM module. And so
then you can deploy your packages via your own custom APIs instead of a generic flight
resource. I I don't know if that all made sense. That was a lot of words.
But, yes, thanks for your question. Yes. There's a server side operator called the air traffic
controller. And if you wanna install it, there's a OCI package that you
can use with you. I got I got it here. So I got that again from
your documentation. There's a page on ATC. So we can actually just do a Yoke takeoff
with this information here. We can run this. So
while that does it sing in the background and I'm sure it's gonna pull some images,
I do wanna play around with my q one because I was quite happy that this
worked. So Yeah. I could just take arbitrary q code and change my replicas to
two and then do my queue export again. Yeah. And and
what's interesting here is you're doing a bunch of stuff in queue. And just because we're
in the Kubernetes landscape or the Go cinematic universe, because queue
is also a bunch of Go packages, you could and I I'm not don't do this
on the livestream. It would be a little bit of bubblegrease. But you could technically write
a ton of stuff in queue, embed it into a Go program, have the Go program
just evaluate your queue just by using the queue packages, and that would be a
valid module. Right? And it would be shipped as WASM and you
wouldn't need to do this piping stuff and you can make it shareable and exportable to
other forms of of of Yoke style invocations. But don't do that. It's
an academic process. I've done that a lot. I I use Q a lot at work
and we we use it natively through Go and it's definitely something you could do with
Yoke, just it takes a little bit of elbow grease. I
don't know if you're speaking. Okay.
Can you hear me now? Now I can hear you. Yeah. My microphone decided just to
disconnect from the Mac. So all I was saying was that is very cool.
I am definitely going to kick the tires up, play with that. But I agree that
that is not for right now because we don't have a lot of time left and
I feel like we've just scratched the surface of stuff. However, what we do have now
is ATC in our cluster. I'm gonna run API resources. We
can see here we have airways, cluster flights, flights. So, I mean, I can start explaining
this and try to get an understanding of it, but I have you on a call.
So can you just break this down for us? How do we interact with airways, cluster
flights, and flights? So that I could I could probably guess what flights and cluster flights
are. But, you know. Yeah. Yeah. So flights are just the generic resource. So right now,
you're deploying you were deploying things through the Yoke CLI. But if you don't want to
be deploying things through a CLI, which is totally understandable, that's not we work anymore. Maybe
you wanna use ArgoCD or you wanna use Flux or you just wanna commit some YAML,
have a high level resource that deploys your your package, you could do that through the
ATC and by using a flight resource. It's just a generic resource kind to deploy flights.
It's kind of the analogy to a Flux Helm release, right, or an ArgoCD application that
uses the Helm source. So that's the and cluster flights is just the same thing except
for a cluster scoped version of the flight. So and then
Airways is that more generic resource that basically allows you to
declare your own custom type. So it's a wrapper over the custom resource definition type.
And all you do is you bind it to a WASM module, and then you'll be
able to create your own your own resources. That's a funny Boris is loving
your aviation theme, so Well, that's worth a star. Right? Yeah. Exactly.
But yeah. No. So you with the airways, you could create your own custom resource API.
In the docs, there's a couple of few commands. There's a I don't know if you
found it. There's a a shell script that allows you to create what we call back
ends, which are just, you know, deployment service and ingress, but I think in
this case just deployment service. And you could install that Airway into your cluster and deploy
back ends that way. Oh, but you're gonna do this one first. That's fine. Yeah. I'm
I'm exploring the documentation. I'm just I don't wanna keep, like, unsharing my terminal to
share the docs and stuff like that. So I would just encourage people to go look
at the docs. Yep. But, yeah, there there's everything is kinda well documented here, even the
all the go code, etcetera. So I'm just kinda jumping around. I've got an airway here
too, so let me just paste this in. So these are just two examples from the
documentation. So the flight, I think we understand. This is hopefully now almost well known concept.
We pointed to the WASM. It supports OCI. This is just a straight HTTP version. We've
got the inputs, and then we've got some sort of args here. Again, this is just
gonna be plasting, I'm assuming, to the Yoke CLI assumption. It yeah. It doesn't it doesn't
call the Yoke CLI in the sense that Yoke is basically a Go SDK. And so
the CLI is just a wrapper over the Go SDK, and the Air Traffic Controller is
also a wrapper over the Yoke SDK. It's just a a nuance, but it's essentially, yes.
It does the same thing. It calls the same code. It's just not calling the CLI
directly. It's a very nitpicky definition or nuance, but yes. Yes and no, but mostly yes.
Okay. So what I don't think I understand so far is how the airway fits in
then. So is this Okay. Okay. In Airway, if we zoom out, do
you with analogous projects. Right? Do you know what a helm not a helm. My
god. A a cross plane composition is? Yeah. Yeah. Yeah. XRD. An XRD,
it's it's that. Or a crow resource graph definition, it's the same thing. Okay.
Yeah. Or it serves the same purposes. It's not exactly the same thing, it serves the
exact same purpose. That is that meta that meta object. Okay.
So according to the documentation, Airways have three modes, standard, static, dynamic, and then
it's funnily it says the three modes, but then also less subscription. That's like a fourth
mode. Oh, yeah. I write my docs, so there's gonna be a mistakes for sure.
Alright. So how the standard static dynamic subscription, do you wanna give us the TLDR
on what the what means for the end user? Sorry. That's is that a hard question?
No. It's not it's not a hard question. I mean, this is just the the this
is, like, the really cool things that you can do that are a bit more advanced.
And so I don't know if you've laid the foundations, but I can definitely answer the
question. So it's just that, right, when you create your airway in the same way that
if you created your cross plane composition, right, you would your XRD, you would now have
a new type of resource, right, that you could you could do, right, that you could
create. So if we created a back ends airway, then we would be able to create
resources of the type back end, and the ATC would would manage the back ends, and
it would create the sub resources from that back end, right, depending on the WASM module
that we give it. And what's cool is that when we are running in the air
traffic controller, we are now in a reconciliation loop. And basically, if
you're running in in the normal static or normal standard mode, it just means when you
create when you update your resource, you would update your back end resource or whatever kind
that you chose, right, to to build using an Airway. When you would update that resource,
we recompute the the the the the sub resources that make up your package and apply
it. And that's all that standard mode does. And if somebody goes in and tries to
create Drift, then the ATC does nothing. It only watches for changes to the to the
top level, you know, back end resource in this case. If you go static, then the
ATC would reject all changes to sub resources because it's also a admission controller. So
it it can say, hey, no, like, you're trying to create drift here. This is a
static airway. We're not allowing drift in here. So that's that. And then for dynamic
mode, it just says if anybody tries to modify one of the resources
that we own, one of the sub resources, then we just recon we reconcile. Again, we
just reconcile. So it's kind of like a self heal mode. But it can do something
really interesting and this is a concept that we talked about at all, is that these
Wasm modules can actually fetch state from the cluster. And so you can actually
read other resources and this is all opt in and you can secure it. I'm very
security minded. None of this is on by default and you can really constrain what you
can and cannot read from the cluster. But you can read other resources from the cluster
and you can read resources within the same release really easily. And so what this means
is in dynamic mode and subscription mode, you can basically listen for events for
changes to releases in your package or to releases outside of your package if you've enabled
that. And whenever a change is triggered, you can reconcile. And so and
so you can actually do orchestration. You could deploy your package and it could run a
job and you could run you could wait until that job is complete and then dynamic
or subscription mode when the status becomes complete, you get recomputed and then you could go
on and create new resources. And so you get to you get to build like reconciliation
and do all these types of really crazy orchestrations or just do self healing. You can
just basically do a lot of things. It's basically, I've let you implement a reconciliation or
your own kind of high level operator just without having to, you know, use cube builder
or think about anything. You just have to create your airway and build your implementation in
Wasm or using some language, and and you just deploy it and it works. Any
questions? Many, but I wanna see this in practice.
So I think what I wanna do first is let's apply oh,
what the hell did I call that file now? More dot YAML. Horrible name. Okay. Namespace
foo. That's my fault. That's default. So
we've now applied a flight custom resource to the cluster where we can run get flights.
We can see it there. And if we run kubectl get pods, we now
see the flight yaml is in container creating. So the ATC controller
detected the flight custom resource and has now reconciled it and we have that thing. My
first question is, can I use the Yoke CLI to black box and get a look
into my cluster? And the answer is yes. I can. Okay. Cool. Yeah. Now
the next question is this state here, this is all derived
from the cluster. Right? None of this is is locally on my machine. Okay. No. That's
not cluster. It's it's So It is it is a secret engine kind of like how
is. So if you do kubectl get secrets, you'll you'll see you'll see some some some
note keeping that Yoke does in your cluster. Okay. So now we come on to Airways,
and I'm just explaining airways.spec to kinda see what we can do here. So I
just yeah. So I understand the modes based on what you've just shared with me. What
I what I do understand is okay. The big one is template.
Yeah. There's a there's a field called template and that's the CRD definition. So this is
the big one. You define your your CRD and wasm URLs. Those are the two big
ones. So it's the the the the the last field and the before before last
field. They're the two big ones and then all the other ones are really customizations that
you can do to behavior about how you could reconcile it. But the those two
fields are the big ones that you need to know. Okay. So airways okay. That's just
for for custom resources then. Okay. Alright. Now that that now answers things. Because when you
were talking about the whole static concept, was wondering, does that actually prevent drift if I
were to to, you know, get deploy and then to edit deploy
flight.yaml. So this was our controller operated one. Right? Yeah. And does not do
it on on this one. I don't have modes on generic flight resources. That
is in the backlog. There is a concept of drift interval where
you could you could specify, like, hey, like a self healing time out and say, please
reconcile this every, you know, every five minutes or every ten minutes or whatever is your
thing. And then it will, from time to time, just check it and and reapply it.
That's the thing that exists in the flight resource. Yep. But it doesn't have the same
modes as the airways do. Okay. Gotcha. Okay. That fills in a lot of things that
were popping around my head. So I feel like that I understand that a lot better
now. So that is that's great. Awesome. Alright. We've
covered quite a lot so far. We have used Yoke with Go, with strings,
very simple string example. We got that to the cluster. We then migrated that to using
Go types and the Kubernetes SDK to then codify all of that, apply that to the
cluster, understand how the turbulence mode works with Drift to see that and fix it, which
is all very, very cool. We've deployed ATC. We've taken a look at the flight custom
resource and how we can do that programmatically as well. I know that can integrate with
VargoTD. That is all very, very cool. And then we also take a look at just
using a queue approach, which could be any binary. Right? I just happen to be comfortable
and familiar with queues, so I use that. But people could use, I guess, you know,
JSON as they're still living ten years ago. Right? But whatever. Mhmm. If you wanna use
Perl and spell YAML, feel free to. It doesn't really matter. Okay. Is there anything else
you want to cover before we move back into big face mode and just have a
bit of a a conversation again? In terms of of raw features
of Yoke, what it can do, I mean, we've scratched most of it. You we could,
you know, if you ever decide in a couple months to invite me back, you could
look at the air traffic air traffic controller in in in full depth. But, no, it's
it's it's a good high level overview. Alright. Let's pop let's pop up here. Oh,
sorry. We're not gonna but the last thing that was like, oh, you could show your
your your your viewers is that the Helm support is also kind of important for
people who want to to see that it it is possible. But, you know,
it's it's it's icing. It's cherry on the on the cake. You know? Alright.
I mean, I don't really care about home support, but I guess other people are is,
unfortunately. It's it's a part of Kubernetes. Right? So I'm just taking a look at the
documentation here. What I see is we could pull a Helm OCI artifact. And
then what else? Okay. So Yoke has a helm. I should just share my screen. I
know this is really annoying, but I'm I'm gonna do it anyway because it's I need
to work out why my computer is being so weird with this. Here.
Can you see the Yoke docs now? I I could see them for a second, and
then they they flew out of the oh, now they're back. Yeah. I really need to
get this fixed. Alright. We're on the Helm capability page. So we have the ability to
embed a chart as a zip archive, progressive migration, and then generating flights from Helm chart
repositories. I assume this part here is probably what is gonna be more interesting, but please
feel free to correct that Well, I mean, it is the most it isn't very interesting
in that I just built a small tool. It's not like at the same level of
quality as the neck as the rest of the of the project, but just like a
it's kind of like a script scripting layer that just basically pulls charts and then generates
a Go package just to make it, like, convenient. And it uses JSON schema to try
and build the types because types are seemingly important to the project. But at a
really high level, if you go up maybe to embedding charts as a zip archive, if
you just pull a chart onto your machine, right, you do helm pull, you're going to
have a tar g z file. Right? And you can
when you build programs, Go programs, and I'm sure other languages and Rusten too, but I
do most of my support work in Go, you can then embed those assets or
those files directly into your program. So if you see there's a Go embed directive in
the code right above the archive, there's the embed package there, and we're using Go embed
a Go embed of that Redis TGZ. And since we have the Helm tar
directly embedded in our program and that Helm is also a Go, you know, like I
said that before, Go cinematic universe, it's part of the Go ecosystem. Yoke just has a
small convenience wrapper over Helm, and you're able to load those archives, load those charts
into memory and use them. And so this is you know, when you asked me that
question earlier about is there any way to to get adoption in
this world that's, like, so home focused, I don't know if this is gonna be enough,
obviously, but at least there's a path for people who want to, you know,
still use the Helm ecosystem, because it exists, but don't want to be using Helm anymore.
So maybe they wanna use Yoke, but still use the Helm ecosystem. There is a path
to doing that. And if you have your own charts that you're maintaining internally within your
own platform team, you can you can definitely still embed them and render them
in Yoke and start to gradually shift and start writing more and more of your logic
in code and less of and less of it in templates and kind of do that
migration path, slowly. So it's kind of like I'm I'm I'm calling back to a really
old question and I just kinda think that, you know, you you scratch air traffic controller,
the CLI,ArgoCD, and then I just had to mention that that there is some
helm compatibility for for those who can't live without it. And and yeah. And I'm excited
to while you're still scrolling your sheet you're still sharing your screen, there's a little tab
at the bottom on the left called videos, and this will eventually end up there, I
hope. So that'll be, that'll be fun. It's a little meta Yeah. Yeah. I think
that kind of degree of Helm support is really important. Right? Because as much as we're
not big fans of Helm and I'm sure that is not we're not in the minority
there, I would say, is that people do distribute Helm packages and charts, sorry,
for the stuff. Like, if you want to deploy Kafka or Redis or MongoDB or
any of these things and you're not using an operator, then Helm is the way you're
doing it because these companies provide Helm charts And being able to just utilize that, like,
you know, that horrible horrible saying of don't throw the baby out with the bathwater, like,
that kinda feels like what this is doing right. It's that bridge and to what is
a don't even know what the word, common deliverable
format in Kubernetes. Everybody has there's a HelmTrack for everything and, like, why not take advantage
of that until we have something that is all encompassing and better, but that day is
not there yet. So very cool support. Alright. Let's pop back over here, and we
can chat. If anyone watching has any questions, please to the comment section. We'll do our
best to answer them before we wrap up today. So question that I always like to
ask when we get to this stage is just like, you've been working on this project
for a while now. What we've done is dip our toe in, right, show people its
capabilities, how they can start to take advantage of it. I think there's a a lot
to love from the As Code approach, you know. I that's again a common sentiment when
I speak to people at conferences is we want to use our tool chain or languages
that we are familiar with. And you know what? Even if we're not familiar with them
now, because let's say that we all have Cloud Code, Codex, Gemini, whatever. It's never been
easier. Code is now cheap. So adopting it to do things like this is a fantastic
thing. What is next for the project? Where where do you see your your roadmap leading
you over the next three, six, and nine months? So the project is still pre
1.o. I don't think I think it's been stable ish, pretty stable
for the last eight months, six to eight months. I've been developing this since January 2024,
so it's been about two years. The first year was developing
the core CLI and SDK, and then the the second year was really exporting it to
support ArgoCD and support its own server side operator. I think that
right now, the shift has been into stabilizing the APIs and eventually
getting a version one. And right now, I guess I'm also just in this mode where
I'm doing outreach and doing talks and, you know, trying to get a little bit of
adoption. And, and there there is there has been some companies that actually do run this
in production, mostly the ArgoCD plug in. But, yeah, I'm just trying to get the word
out and stabilize everything and get, you know, as many feature requests as I can. And
whenever I get new whenever I get new users, I get a bunch of requests, and
that's when the the project grows the most, and I have, my most fun. Alright.
And and people are watching this and going, okay. This is a cool tool. I wanna
contribute. Right? Are you open to contributions? Do you accept AI contributions? Like, it's a very
topical thing right now. Like, how do you feel about that? So I am open to
contributions. I feel really bad as you're saying this because I have one person that's trying
to contribute to contribute for the last month, but I've been giving talks and too tired.
So I I've I feel like I haven't been doing my my best as a as
a steward. But, yes, I am open to contributions. I love it when people, you know,
join the Discord, talk about features, talk about what works, what doesn't work, what
they would like it to do. And, basically, I my goal is always
to keep the project as agnostic to how people would want to use it. I want
it to be just, like, foundational in a way. I don't wanna be too prescriptive, and
I just wanna just support the the goal of the project is to support code based
tooling for for for Kubernetes, which whatever is your your Kubernetes workflow that suits you best.
So, yeah, that would be my first answer. And then as to the AI thing, I
don't wanna out my personal stances. I'm I'm adjacent to the Zig
project's stance on AI. I look. If you if if I don't really mind what, you
know, if the contribution is good. I just want the human to be part of the
loop. Right? Sure. If if it's a human that, you know, uses AI and they've they
understand the project and they understand the code and for some reason they they don't wanna
write it with their hands, then that's fine. But if they're doing a drive by and
they don't know the project or understand how things fit in or just want to ask
Claude to ship in a feature for them, then that might not take priority over over
other work or other contributions. So Yeah. I think that's fair enough. And I think,
well, AI does make code cheap. Comprehension is not cheap. People still need to read the
code. Right? You still got to know what you're deploying. You still gotta be accountable. Right?
Even if AI writes the code, the human that does the push, opens the PR, whatever,
they still gotta take responsibility for that. So, yeah, completely agree. Anything else you want to
discuss before we we say goodbye? No. I mean,
I've been very comfortable letting you drive the show. So I I'm not this specific other
than just thanking you for, you know, responding to to my, you know, cold outreach and
making this happen. What I would suggest is definitely let's schedule a follow-up when
there's more to show. And, you know, if when you have that next release ready to
go, please just let me know. I'd be happy to jump on and take another look
at it. I know that over the next kind of weeks and months, I have my
own production that are unfortunate. But and I do wanna find ways to make
that more as code approach. So I definitely see myself getting involved and trying to kick
the tires on this a bit more. And I was encouraged, Emma Watson, to do the
same, but no drive by AI commits, please. Alright. Well, thank you so much for your
time, David. It's been an absolute pleasure. Thank you for working on Yoke and bringing that
to people. I hope they find it as valuable as I did. And, yeah, until the
follow-up, we'll see you all next time. Cheers. Thanks so much. Have a great day. Thanks
for hanging out tonight. Brought Code Academy,Live, andSly. You brought the chat, we brought
the code. Wasn't sparks on the Kubernetes Road. So raise a hand for David too. We're
walking through what y'all can do. Flights took off, the charts got smoked. We signed the
hash and ship the joke. We'll see you next time. Same Loud Track. Bring your questions.
We'll be back from the runway to the cloud. Thanks for joining. You were loud.