wasmCloud Community, 27 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: wasmCloud: Polyglot Actors & K8S Rust State Machine Operator - 1/27/21 Community Call

Description

Two great demonstrations this week in the @wasmCloud Weekly Community Call -

1. @brooksmtownsendabsolutely crushes another @wasmcloud demonstration featuring a seamless collaboration between polyglot actors in Rust and AssemblyScript. #CloudNativeWasm #WebAssembly

2. @kevin_flansburg then shows off the new Krustlet Krator: a Kubernetes Rust stATe machine operatOR.

#wasm #github #community #node #js #compiler #compile #browser #cloud #computing #programming #development #software #inspect #data #application #contracts #microsoft #archive #metrics #oss #opensource #wasmcloud #webassembly

A

uh Welcome to uh wasn't cloud community meeting for january 27 2021, uh where we're trying to enable developers to uh build their services and webassembly and run them everywhere.

B

We've got a couple new members this week, uh john mark walker, you wanna, do an intro greetings yeah. I run the open source program office at capital, one. I am a new convert to wasmcloud, so I look forward to seeing what we can do with it.

A

Awesome and thank you and we've gotten into a tradition of starting off our calls with a demo, and this week we actually have two demonstrations.

A

uh Microsoft will be doing an update of the crestlet demo, but they're unable to start until 1 30., uh so brooks is going to get us started with a demo brooks I'll hand it off to you.

C

All right sounds great. uh I might also need to be co-host so that I can share my screen.

A

uh Yes, hold on just a moment so.

C

While liam's getting that ready, yeah, I'm brooks townsend, I believe I met most of you on here, but I work at capital, one uh with with kevin on the wasmcloud team been doing this for a few months. There we go.

C

I got it so what I'm going to be showing you today is the polyglot actor experience with wasmcloud, so how wasmcloud supports polyglot actors and how our use of whittle and our generic actor interfaces define the contract that actors and providers can communicate on regardless of how or what language you actually write your actors in so to get us started, I'm going to share my screen. You should be able to see a pretty blank visual studio code window now.

C

So let me know if you can't see it, but I'm going to start us off with a little bit of a business app proposition so for this business app. What we want to be able to do is write a program that can increment a value in a key value database as a response to an http request, pretty simple, uh pretty simple idea, but what this does involve is interacting with a key value database and acting as an http server.

C

So writing this outside of uh right outside of wasmcloud, say in like java, or go, for example, you're going to be bringing in all this shared library code and working with language, specific libraries and lots of boilerplate code just to get to writing your actual business logic.

C

So I'd like to show you how we tackle that with wasmcloud, starting with our interfaces, so we write our interfaces using uh the webassembly interface definition, language short for whittle. If you would like to learn more about whittle or what we're doing with it.

C

Our last community meeting last week uh had a demo hosted by phil ketty, which was awesome showing off the wapi-c klee, and the uh whittle as a spec so definitely recommend checking that out on youtube, if you haven't seen it yet, but for this demo, what we're doing with these interfaces is specific to our kb counter actor. We need to define what it looks like to be an http server, so this whittle is fairly simple.

C

We're defining an interface with a single function called handle request that takes in a request and gives back a response, just like a pretty regular http server and we're defining those requests and response types here.

D

Next, the interesting things to point out here about this contract is the contract, is a business level contract. So it doesn't contain any information about how the what the http request comes in doesn't contain anything about uh port opening or threading or any of those other things. It's purely an abstraction around the business idea of responding to web requests.

C

Exactly yeah thank you kevin, and you can also see that illustrated here with our key value contract.

C

Looking at this, if you've interacted with a key value database before these things will all look familiar generic operations for getting keys and retrieving a value out of a database adding a number or adding a value to a certain key in a database.

C

These are just abstractions around what a key value interaction is supposed to look like, and this is what we need to write as our generic interface.

C

Now that we have that generic interface, I mentioned the ypc command line interface. We can directly from this whittle generate language, specific interfaces for our actors to use. So I've already gone through the process of doing this to spare a little bit of time for the demo, but taking a look at the rust, http server interface.

C

This is all of the code that's generated for us using the ypc tool, so the ypc command line tool. So you can see some pre-generated structure for a capability provider host on a certain binding.

C

The important part here is the single function handle request, which is what we defined in our interface, which takes in a generic http request, returns a response and the structures for a request and response types. So you can kind of see the api being formed here for rust actor to be able to interact with these generic types same thing with key value, but we can, like, I said, we're generating these language specific.

C

So I'd like to show you the http server generated version, while it's fresh on your mind for assembly script, so for assembly script, we're going to see largely the same structure, a host class over a certain binding with a single function called handle request, and if we scroll down a little bit, all of this is pre-generated, so the extra glue that's binding. All this together is not something you need to worry about. We have a http response class for in a typescript module and a oh, I passed it and an http request class.

C

So all of this was automatically generated from a single command from those whittles. The interfaces that we wrote- and this is how actors are going to be enter interacting with these uh resources through these abstract interfaces. It's also I'm gonna chat, I'm just gonna make sure it's not anything crazy. Yeah thanks liam yeah.

A

I was just gonna paste into uh from last week. um I uh it's in the notes and uh the documentation for using the klee to do these two generations from your widows here. uh The first command to type in would be.

A

You know something like um the clea new assembly script, hello, world right, uh brooks and then once you've uh edited your whittle, then you can use make in order to uh generate your um actually compile your whittle into your interface. Is that brooks? Did I get that right.

C

Exactly yep, and um that was shown off really well last week in the community, call um definitely recommend checking that one out, because all the generated code that I just showed you is only output from that ypc new assembly script, http server and then running make so from here. It was all generated from this interface that we've written here for http I'd like to show.

C

So uh both these rust and assembly script actors are going to be interacting with the same common interface, with their own language, specific things that have been generated for you now, this team, that's trying to implement this business app. So this kb counter app have two competing developers.

C

One loves rust because they've been working with it for a while, and they like uh some of the aspects of the borrower, checker and one's going to be working with assembly script, because they are completely convinced that the smaller binary for assembly script way outweighs the benefit of any other language, and so these two competing co-workers are going to write their own kb actor and we'll see what that looks like.

C

So opening up the actor kb counter for rust. This is the entire program, so we import a couple of libraries, including our generic http server interface and the generic key value interface.

C

We have a single function called ypc init up here, which is our the entirety of our boilerplate here to register a health request which is used internally for the host and, most importantly, in the http module register, a function that's going to handle http requests, so this function is increment counter. It takes in a request and returns a response.

C

All it does here is takes the path of the request, and it's going to add one to that value in a key value database notice here in this actor.

C

As we're writing this, we have no idea how this http request is going to get here where the response is going afterwards, more, notably, what type of key value database we're even going to interact with here this default function is doing, is instantiating it on the default binding, which is almost just like a name space in kubernetes, but we don't know if it's going to be redis or cassandra or maybe even an in-memory key value on the other end.

C

So this is what an implementation may look like with rust. With assembly script.

C

We can see here a decent amount, more color from the visual studio code highlighter, but mostly the same some shared types from the actor http server interface, a ypc init function to register your handlers and then a handle request, function that takes in a request sends back a response that initiates or instantiates a key value host and adds one to that adds one to that key.

C

So, what's completely absent from both of these is language specific boilerplate code for interacting with http servers or or key value databases.

D

And basically, the main reason why there's about 10 more lines of code in the assembly script- one there is in the rust one is the assembly script doesn't have some of the fancier json macros, so we have to construct our json object by hand here.

C

Yeah, um even then, with all that stuff I mean this is maybe 10 lines of code to um to do all of this.

C

So the key thing here there both of these actors, are interacting with the same common interface generated from that whittle definition that we came up with so now, I'd like to show you what this looks like in action running with wasmcloud. So I'm going to open up my terminal, we're going to use the wash command line tool and the up command to launch an interactive repel for wasmcloud.

C

What this does is launches a host that we're free to interact with directly in this repo, and we can see, I got a do a fun tmux thing.

C

We can take a look at this host's inventory and see that we have uh two providers running in it currently which are core to just wasm cloud running uh its core program. So we can start by scheduling our rust kb counter actor, which we have uploaded into our god. It is hard to type and talk.

C

At the same time, we have uploaded into our azure container registry, um which is an oci compliant registry, and it's where we host all of our artifacts and we can also host our schedule, our assembly script actor into the same host, we're not specifying what host this is because uh we only have one running and it's going to respond to the auction of hey I'd like to schedule this actor. So we can see those two actors are running.

C

The next step is going to be scheduling our capability providers, which is the thing at the other end of the interface. That's actually going to be implementing this part so or implementing the functionality, so actors will always interact with a key value. Abstraction, for example, redis is going to be the provider on the other end of the black box. That is actually going to interact with the database and retrieve values for you now that we have those actors and providers scheduled.

C

The only other thing that we have to do is link the providers and the actors together. So what this does just connects them over a certain contract so that they can uh interact over that contract and start making code happen.

C

So we can do that by running link with we'll start with the kb counteractor public key, the redis public key over the contract, wasm cloud key value, and this connects to redis over. I can't see over localhost 63.79.

C

I have it running in the background uh already done for this demo and then we can also link the uh rust kv, counter actor to the http server provider over our wasmcloud http server contract and we'll schedule this or we'll we'll have this listening on port 8080..

C

Now I'm going to do the same thing for the assemblyscript actor, just link it exactly the same to redis and to http server. The only difference is I'm going to put the assembly script actor on port 8081 just so we can have a little bit of difference and that's it. So all of our actors and providers are running in this host and we have linked them together so that they can. The provider can appropriately talk to redis and they can appropriately interface over this contract id.

C

Now, let's see what this looks like.

C

So if we curl localhost at 8080, which will be our rust key value, actor is sitting on the other end of this link to http server and we'll do something cool like wasm, community demo and we'll see what value is in that database, since we haven't queried that before it's going to add one to a non-existing, key and return one. So this is entirely what it looks like for an actor to receive that http request increment that counter and send it back over the wire.

C

Now the cool thing here, if we swap out this port to 8081, we're now going to be talking to an assembly script doctor doing that, you notice that the count continues to increment as it was before, and that's because it's linked exactly the same to the redis provider and http server provider. You can only really tell that it's different from the fact that our payload is slightly different from rust. We set up a payload of counter and from assembly script.

C

We do it of count so that you can actually see a difference, so at the end of uh or through this curl really there's there's a couple of awesome things that are happening. First of all, it makes no difference to the end user. What language? You actually wrote your assembly script actor in. So, of course, that's what you want from any program. No end user should really care what language is like implementing that functionality under the hood.

C

What this means with our generic interfaces is from the provider perspective. So when we write a redis provider over the wasmcloud key value interface, we don't need to care what actor, what the code, what language the actor is going to be coded in as long as it implements that common interface and communicates with it. That's all we care about and the impact for the developer here is these two developers on this team that wrote this typescript and or sorry assembly script and rust actor they're, both free to use whatever language they.

B

C

Because, as I've as I've been hammering in as long as we're communicating over this common interface, the language is completely arbitrary. As long as it can use that interface and compile to webassembly, then it's perfectly fine as a wasm cloud actor.

D

Yeah and because these things are wise and cloud actors in their their web assembly modules, uh any of the actors that you write in any of these languages, they don't take a direct dependency on a web server. They don't take dependencies on redis or cassandra or any other non-functional requirement. They have. No. These things are truly freestanding with no external dependencies.

C

Exactly if we decided to use you know, if I do this demo next week with a cassandra provider, I won't have to change this actor for either language at all.

A

I'd point out that this is, you know from the enterprise perspective, where you know you're running fleets, of thousands of applications. This is one of the biggest uplifts in the life cycle of this app. You know the when you you have those dependencies baked into your apps. You also are baking in their management. So let's say that there was some redis library or cassandra library baked into this when there's vulnerabilities or updates or anything along those lines, it requires compilation and recompilation and recreation of artifacts and redeployment, so we're decoupling.

A

The life cycle and management via these generic actor interfaces. That is uh you know, from a fleet perspective, um is one of the uh biggest um crisis in enterprise development. uh Today,.

C

Yeah, does anybody have any questions or want me to show a little bit more code here, happy to poke around.

C

I guess there's not that much more code.

D

To show, I know you've demoed this before, but uh I would love to see this again uh and I'm sure there's probably a couple people on who haven't seen it. But can you show using the rebel to make those invocations directly without using curl.

C

Sure, let me just grab exactly what I need there. So all you need to do here is: we can use the call command to directly to directly invoke one of these things. So when you curl one of these actors, it invokes the http handle, request function and then that carries out actually returning the response to you. We can directly call this actor uh at its handle, request, function and uh directly get a response back without actually having to curl.

C

So this just looks like running cuddle call with the public key and then the invoking the handle request, function and uh relevant to the demo. We we provide a complete json payload of an http request. So what was my? What was my key here? Wasm community meeting wasn't community demo.

C

So if we call this actor's handle request handler.

C

Let's see that should show up there.

C

Kevin I almost got through a demo without something going wrong.

D

Yeah this time, it's absolutely my fault for asking you to do this too.

C

Is that the right one that is where I won? Let's, try the assembly script, actor.

C

It is actually possible that I have this payload copy from an old version of the interface, so it.

D

Looks like the interface is having a parse problem. It's not it's not making it to the actor. So it's it's washed.

C

Out the issue, I actually know exactly what it is uh in the repple. This little single quote will throw it off darn all right. It will throw it off, but.

C

There, it is uh the yeah, the payload can't be surrounded in single quotes in the rebel, but calling this directly. uh We get this raw json payload back because uh we're serializing with message pack, and so it looks kind of corrupted in the beginning, but the body is still serialized the same.

D

So this has a huge, huge impact on developer productivity and being able to test your own stuff, because you know when we're when we're trying to do cloud, microservices and lambdas, and all that stuff being able to poke and prod the business logic. In the absence of all those non-functional requirements is usually uh impossible. It's super hard to do with aws with lambda it's even hard to do for making you know microservices with go and whatnot, but here you can poke and prod any actor independent of the provider. That would normally do it. For you.

C

Yeah we can actually stop the http server provider entirely and just directly interface, with this actor.

A

I think that's an understated point right there, for um you know, testing and things like that um brooks. This has been a really awesome demo, like you know, we've been kind of working towards this vision for such a long time, it's kind of wild to see it. You know all working in different languages simultaneously.

A

Does anyone else have any questions or things they they want to dare brooks to do?

A

I think we're at the double dog dare at this point um if anybody wants to violate protocol and move right to the triple dog deer, I think that's acceptable in this context.

A

All right brooks all demo. Man thank you. That was a. It was a great one yeah. um So let me just share my screen, we'll get back on the agenda here, because I know we've got another demo uh today, um some quick community activity. um I want to make sure that everybody's aware around two events. uh The first is the cloud native wasm day, that's being put on by the cncf uh as a part of uh and building up towards a kubecon eu.

A

The call for papers is open and the intention is is to pull together anyone and any effort that is really um around. You know the intersection of webassembly and cloud native computing there. So andrew brown. I would really encourage you guys to submit a awazi nnn. I think it'd be a great place to demo what you guys are working on uh microsoft team. Obviously you know crosslit bindle, all the things and uh wasn't cloud team uh as well as far as getting um some events um up there now, uh and then there is another.

A

uh There is a shortly before that uh this is on, uh may may the fourth, um uh so, hopefully we'll see some uh baby yoda branding. uh May the fourth be with you uh and uh there's another webassembly summit, uh that's currently being planned for april 22nd, uh and I apologize the c4p the cfp for this one has already closed, um but I'm really looking forward to this one as well.

A

I have been told just for planning that the coop county eu event will be an online only event, but already thinking ahead towards the end of the year that the kubecon us event will have both an online and an in-person component in los angeles this year. So uh just looking ahead to uh planning for um uh the future. um Are there let's see the wasm time other community events, uh the regularly scheduled bosom time call is next week on thursdays at 4.? Are there any other community events that people should be made aware of.

D

There's the um the the runtime working group, um I don't have the specific details, but I can post it up there in the in this uh google doc. Okay, uh it's not wasn't time related, it's just the uh the cncf webassembly runtime working group.

A

Yeah I'll make sure we get it linked in here for the notes when we post them uh kevin. I was just putting a note on for the uh wasn't um meeting um uh with um uh with the demo uh from uh on crosslit uh coming up. I think we've got uh kevin uh from microsoft.

A

um That's supposed to join us, not.

E

From microsoft,.

A

Not from microsoft, no.

E

I'm just one of our fellow core maintainers on crestlet.

A

Okay, well, look uh kevin! um Let me uh you know, we didn't actually offer you you weren't here at the beginning of me. I know you had a conflict. Let me make you a co-host here and if you wouldn't mind making uh maybe doing a quick introduction and uh we'll let you uh turn you turn over the demo for you.

E

Sure sounds good.

F

E

E

Am I good to go cool uh yeah, so uh I'm kevin um I've been working on the crestlip project, for I guess since may april, or something like that and I mostly got involved- I'm not um super involved in like the wasm uh scene, but uh I got involved because I'm really passionate about rust and I've. I've been working with kubernetes a lot lately, and so that was kind of a good intersection there.

E

um And then um I guess what we were planning to demo today was um actually a new crate that we've split out of crestlet called crater and earlier in the fall, we moved presslet to using a state machine model for sort of defining and then managing the.

E

Pod states within within uh the the crestlet um so crestlet is a kubernetes uh cubelet sort of replacement written in rust. um That's still very beta, but essentially we wanted to improve the reliability of uh sort of managing pods as they move from, like you know, being registered, to pulling images to running and then eventually exiting um so we, we came up with a new state machine api for that um it got quite a bit of good reviews from people.

E

Who've taken a look at it in the last couple of months, and so we decided to split that out into its own crate, which allows you to write sort of more generic operators using the state machine api in rest.

E

That was just sort of some of the community feedback we got was that people were excited to to write their own operators, and so um I can share my screen and walk you a little bit through this. um So this is our api documentation.

E

We haven't actually published the crate yet so this isn't actually up on docs.rs yet, but essentially uh there's an operator trait that you implement and you have to define a number of types, um primarily the uh sort of kubernetes resource type um and we leverage the kate's open api types here so that it should.

E

You should just be able to use those right out of the box, and then um you can define your own types for sort of describing like the status and that gets posted automatically to you for you to the kubernetes api um and then there's some types for managing uh the state of your objects. Internally.

E

So and then from there you supply um an initial state and a deleted state. So the initial state is is what it uh starts, the state machine with, and then the the deleted state is used.

E

If the object is marked as deleted in the kubernetes api, it will automatically transition to that state and that lets you garbage, collect and stuff before shutting down so to implement a state.

E

There's really just two methods: one is status which allows you to produce a json patch which gets sent to the kubernetes api and then the other one is the actual state handler which is like an async function that you can use to actually execute whatever's happening in that state like pulling images or or what have you um so that's kind of a high-level overview of um the api.

E

um We have a blog post uh uh surrounding the initial introduction of the api to to crustlet uh that was back in september um and then there's another blog post. That's coming out shortly. That sort of describes um this new crate um and and the api specifically there, um but the focus of that blog post is a example.

E

I wrote um which uh leverages uh cube, cube.rs's, um really nice derived macro for creating custom resources in uh kubernetes, um and I just kind of create a toy example that sort of like, like the custom resources like mooses, it's like kind of silly, but um you can take a look and and see um it's on our master branch right now. um You can take a look and see if this is this example operator that's defined over this this custom resource.

E

So um we implement a trait uh to wrap the status, and this is the state used for internally tracking things about the objects and then there's, I think, there's four states that are actually implemented here. So like it, you know it registers a new object um and then it's the object transitions between like two or three states uh and then there's the deleted state here, where it releases the object and and there's an example of using shared state.

E

So there's uh a type that allows you to have state that's attached to a particular object, and then we also provide some like concurrency uh behavior. That allows you to share information between different objects that are being managed by the operator.

E

So that's a pretty common ask and then more recently, we merged in functionality that allows you to kind of easily detect when the objects are modified. And then you can, you know, transition to a new state to sort of handle, reconciliation of whatever got modified and then finally, I implement the operator trait, which I mentioned before um and then actually in, like launching the operator is pretty simple. I just initiate or create a cube config using cube.rs, uh and then I I this is sort of the main entry point.

E

Is this operator run time which just sort of blocks forever on the the main task? So um I can. I can demo it um so uh I've got some debug logging here that should um show some interesting information and then I've. You can use cube.rs to automatically register the custom resource, but I've gone ahead and defined the yaml myself.

E

So if I create that custom.

E

Resource and I'm just running on kind here, um okay, so here I have uh no mousses have been created, um but I can create an example, um and you can see that uh like it it. This is some debug logging.

E

You don't necessarily have to have this on, but it tells you when it's entering various states and the status patches that it's applying and then I have some logging, that's actually coming from within the state handler, and then I mean there's not much going on here other than you can see that the status phase and messages are getting updated as it transitions between the states um and then I can make things a little bit more interesting.

E

I've created a script to just like generate multiple objects for it to track, and of course I am not in the right condo environment.

D

E

So if I do something like that, it'll create a bunch more and each of them gets their own state machine. They operate independently. That's all async.

E

And so uh I'm pretty excited about this api. I think it makes it really easy to kind of think about how your operator is going to work and think about concurrency between objects, and um you know the the state handlers uh we've uh purposefully made them um infallible. They they don't necessarily.

E

uh They don't return like error types. So the intent is that you would explicitly define um an error state which would, of course, properly update the kubernetes api with uh information about what the error, what error is occurring and then maybe you know after some sort of error back off, you would retry the object, um transition back to a registered state or something- and so that's kind of the pattern that we're favoring is- is sort of that explicit error handling within the reconciliation loop.

E

A

uh Kevin would you mind pulling up the uh github real quick. I just wanted to make sure I got that in the notes, just uh where you guys were on this yeah.

E

Yeah, it's a it's a sub crate uh in the the main crestlet tree right now. um We're actually splitting out some of the providers soon, but I think this will stay in tree for a while. Okay super I'll make sure that's linked in the notes.

A

uh This is a really awesome demo. Anyone else have any questions for uh for kevin.

A

Creator is an excellent name by the way.

E

Yeah, I think we're starting to uh to stress our convention of picking out uh random acronyms from from 50 different words, but uh I thought it was pretty clever.

A

Yeah, the uh I I love some of the early concept stuff for a walk. Still, uh you know web assembly on kubernetes, or uh you know anything along those lines. I I always, I think it's important to try to bring uh like joy and fun into uh into your work as much as possible, uh but thank you so much for attending today and I will also make sure to drop you a slack invite in case you want to come and hang out on on slack with us or or anything.

A

uh We really appreciate the demo great um super uh and um uh I'll make sure the uh the details are linked into the notes there. uh A couple of other items uh coming up just a quick uh check in kevin, has been um uh slang away uh on docs. I know he's really looking for some review and some feedback.

A

If you look on our github you'll, see that there are a number of you know, um requests for review and comments uh up there, um uh and this is um you know, available on netlify and all tied in as we. I continue to develop this live, um so I would just put a general call out to anyone that wants to contribute there heading back over to um where we are with uh current.

A

I kind of just put a call out to you know core team for any asks here. As we kind of look down, I feel like actor interfaces brooks you've been really slaying away at some of this still how's it going.

C

Yeah, it's it's going well a lot of what you saw today with the key value counter for um rust and assembly script involved, creating the http server and key value for our interfaces for both of those languages, so we're cranking away at these. This is a big, a big unit of work left for our 15 release, since um the the rust ones need to be updated and any additional ones like for tiny go.

C

For example, uh we don't have on the road map for getting in for the release, but if you're excited about using um wasmcloud with go, um the issues are out there and we're happy to help push you in the right direction.

A

And um and then phil I I know, you've got a pull request in here on sort of like a um on a reorg of this, a particular repo. Is that correct or there's a branch here? Maybe that has a uh the codegen restructure um and I think if we just show people this, uh it made a ton of sense to me when I saw it for feedback.

A

But now it's organized by you know like http server and then you'd see per language under under here, whereas in the current branch um we've got it organized by language and then by um uh you know, by uh function. um uh Phil any comments on that or anyone else have any perspective on what they like better.

D

Well, I'm uh I'm a big fan of the the restructured way of doing it, so that um you, you discover by the interface or by the contract first and then uh below that you can pick the language that's appropriate. I think it's just gonna be easier to find stuff. That way.

A

Yeah, I agree with you very strongly on that kevin. Anyone else have any feedback on that taylor. Anybody! What? What like just at a glance, what makes sense to.

A

You, taylor drop all right. Maybe taylor drops.

E

No I'm here I missed the question.

A

That's okay! It wasn't a great question anyway. uh I was just asking just at a glance if it made sense to have it by contract by language or by language by contract. On the organization uh I mean that feels a little bit more like a bike shed. I'd probably do with whatever was available.

E

It's not a it's, not a big deal to me. I just may I just make sure it's. It just follows whatever pattern you choose. Otherwise, it just feels very much like a bike shed.

F

Hey liam go back in the repo, if you don't mind yeah sure so go under like key value. I can't remember which ones I stubbed out but go under rust.

F

And then click codegen.yaml.

F

The main rationale for this is see where it says: schema dot. Dot right is that all the languages can go down directory and and they all reference the same um widow file, so the widow files aren't copied and pasted all over the place. I think that was the way it was kind of working before, but um yeah so they're all working up the same sheet of music. Basically, whenever you run your make to do the whole kit and caboodle, there's less um duplication of.

A

The whittles yeah that that makes even more sense bill um to have it. You know one little file and then you know the um uh everything else. It.

D

Derived the whittles haven't been duplicated for months, uh they're, all now in the schemas directory, but yeah it it's a little bit of bike shedding, but we should get this cleaned up before we're done. Releasing.

A

Okay, all right um uh what about uh on wash uh brooks, um you know anything, uh that's uh blocking you or you're waiting on some help with here.

C

um Not for watch same, um I you know, there's there's like two easy punt issues in here. One of them is going to be resolved by just bumping the provider archive version. We had a new version of the in keys and the wascap crate go out this past week, so just need to bump that in wash too, I think the biggest thing uh that that's still outstanding is uh removing the get dependencies from our cargo uh list, so making sure that you know we need to publish wasm cloud host.

C

We need to publish the control interface and when crosslit releases, we can pin to a version of oci distribution, which is one of the crates, that's in the main, crestlet repo.

C

So we're sitting at a pretty good point, most issues that are coming in now, I'm pinning to the 0.3.0 milestone, which is just it's a generic way to say that we're doing it after the 0.15 release.

C

So anything in there with 0.2.0 is planned to be completed with wasmcloud odot15.

A

Okay, all right, so not a lot left here on the on the punch list to get that out and uh so crustlet um all right.

A

You guys uh going there and you know in theory, you know we're you know four days away from uh from like our release goal of 31st, uh and um I still owe the forms of the form for the release party and, of course, all are welcome to that we'll get together and play with our little uh snow globes uh together on a call sometime um anything else, just open call uh kevin uh uh gustav uh chris anybody wanna raise any issues or concerns or.

A

Okay, well, I think that wraps us up for the week I'm going to go ahead and stop recording and everyone's welcome to hang out. We can uh chit chat and talk for a little bit. um Actually one thing before we go is uh demos. For next week we've got um uh as on our to-do list, uh whittle uh bindle, um maybe looking at the new website, if we're done or uh packaging um katakota tutorials crosslit, I wasn't three on small devices.

A

uh Yeoman anybody want to volunteer uh for next week.

E

um When you're talking about yeoman, are you talking about the the thing that we've been working on with the generator for stuff yeah um I mean ideally so ivan on. Our team would be the best at um probably presenting that, but he's a new zealand time, and so it's honestly not convenient for him. I think until at least after, um like 1pm uh central tech time, I mean pacific time, um and uh so that's just something to keep in mind.

E

The wbs is one of us can probably demo it, um but we we can do that and then uh bend will be good too. We're we're actually working through how signing of bindles and everything will work. So um it'll be probably a good time for you. Try once we cut bindle 0.3 out, but.

A

um It's a that's checking along too okay, all right! That's phenomenal! Well I'll coordinate with you a little bit offline on those and I'm going to stop recording.