0:00 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

0:53 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

1:55 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

2:26 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

3:05 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

3:42 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,

4:20 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

4:56 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,

5:29 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

6:00 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

6:35 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

7:09 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

7:42 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

8:18 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

8:59 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

9:38 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

10:11 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.

10:49 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

11:24 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

11:55 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

12:23 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

12:57 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

13:34 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

14:08 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

14:59 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

15:33 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

16:06 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

16:39 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

17:11 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

17:48 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,

18:24 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

18:57 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

19:32 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

20:17 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

20:48 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

21:34 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

22:15 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.

22:55 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

23:30 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

24:08 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

24:47 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

25:25 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

25:56 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

26:45 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

27:20 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

28:07 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

28:41 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.

29:32 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

30:12 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

30:45 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

31:24 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

31:59 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

32:37 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

33:07 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

33:38 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.

34:09 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

34:56 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

36:01 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.

36:49 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,

37:39 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

38:29 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,

39:19 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

40:07 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

40:48 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

41:19 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

42:01 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

42:37 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

43:16 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

44:02 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.

44:42 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,

45:30 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,

46:14 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.

46:54 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

47:31 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

48:06 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

48:49 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

49:26 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

50:23 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

50:57 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

51:35 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

52:14 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

52:49 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

53:31 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

54:08 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

54:54 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

55:26 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

56:02 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

56:39 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

57:17 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

57:55 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

58:29 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

59:20 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

59:58 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

1:00:39 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

1:01:17 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

1:01:56 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

1:02:32 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

1:03:04 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

1:03:41 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

1:04:22 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

1:05:03 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

1:05:33 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

1:06:14 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.

1:06:55 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,

1:07:28 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

1:08:04 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

1:08:40 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

1:09:13 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

1:09:43 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

1:10:35 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

1:11:09 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

1:11:44 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

1:12:22 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

1:12:57 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

1:13:35 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

1:14:07 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

1:14:47 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.