 the network service mesh, the dashboard, that would be helpful. We'll start there. Let's see where's the link for it was on here. Let me just go to GitHub. Yeah, that's how I always find it. If you go to GitHub, then click on Project. Yeah, and so we have a document added on using CNI with Minicube that's been merged in. And we also have added a note for usage on dependabot. So those are the two items that were added in. So if anyone wants to take a look at those two pieces of documentation and see if they're clear and meet and or if there's any questions about how this works, those are the places to find it. So in terms of things that have been working on, we have a set of guidelines that has been written by a person who goes by the nickname Dune Hammer. And can someone remind me whose name is attached to Dune Hammer? That's me. It's John. All right. So John's been working on a set of guidelines for extending network service mesh. So we'll discuss more in detail about that. But there is a document that needs review. So we'll definitely. We've heard of this here. We've moved on to following the action item list to go through the action item review. Yes. Cool. Tom, could you click on the action item review tracking link? Oh, yeah. OK. And that is where I'm really slow today. I don't worry. Not enough coffee. There we go. Right there. Oops. Oh, there it is. Yep, that's it. So we have these guidelines that have been sent in. So we're going to take a look at it on our particular side. But if someone who's not as familiar with how to extend out network service mesh, we'd really appreciate if someone can take a look at it and see if you can make sense of it. That way that we can make this approachable for newcomers as well. So one of the comments from Kyle was whether to be internet or tree. That's the thing I added to the agenda. So I created, based on Kyle's sort of thoughts, I created out of tree template with a script. They'll basically create a complete tree with make files now using Serge's simple data plane as a kind of a template. It's not quite all there. I think I need a few more things. But it's one way of doing it. And it seems to kind of work. I think I've got a few bugs still to get out of it. But I can create different data planes. And all you need to do is really edit the photo file and the go file to get most of it working. What's really missing is some sample endpoints and how to, once you have a data plane, how to send traffic over the data plane. So a little more examples around that would help. Ping. Ha! I'm terrified. I was thinking about a YAML file, Tom. That's right. Ha! You can send YAML files over a data plane, too. No problem. I think you have a YAML file to create different points and then connect them up. So to show a full end to end sample of something saying, I want to use NSM to talk between these two endpoints. How would I do that? Yeah, that is good. Because I was trying to figure out, this should be easy, you know? And in theory, it is. But yeah, that would be incredibly useful. Yeah, and these kind of exercises and discussions, they help out a lot because from a high-level conceptual view, like, we can try to make a simple architecture. But we know that there's a lot of detail that can get down when you're trying to actually implement it. And so one thing that we have to focus on and iterate on and where this can also really help is on how do we make this approachable? Like, if you're a newcomer, you want to create something on top of this that's new. And the two types of experiences that we could provide is one where it's easy. We have templates laid out, generators, or anything that they need just to get started, type in the code that they need, and then they're off and running. Or we could go the opposite direction. And even with fantastic documentation, but just have so much detail in there and so many little things they have to take care of, then it will still be really difficult for them to approach. And that'll limit our adoption. So... I think also you think of, certainly, and one of those to do... There's three audiences really to think about. One is you guys who are writing the infrastructure. Two is the guys who want to use infrastructure to write NSM plugins. And then three is the people who want to use the plugins to actually do something. And in some cases, it may all be the same people, but I think in most three different audiences and how to address the documentation and how to address the how-to's for that to Fred's point. And so there's minimal friction. If I just want to use NSM and somebody else has built a plugin, I should write some YAML files. I should not need to know anything else, really. Is that maybe how to deploy a demon set? If I want to extend NSM, I shouldn't need to know too much of the lower-level details, just enough to do a data plan or an endpoint. I totally agree with you. You want people to know just the things they care about. I often talk about this as keeping things under the complexity curve. So if you picture like an X and Y axis, where on one side you have... On Y, you have the complexity of what it takes to do a thing. And on X, you have the complexity of the thing you're trying to do. There's a 45-degree line there that you need to make sure you always stay below. Right? You always need to stay below that 45-degree line at all times. Yeah. It's not always possible, you know? But yeah. Or try to get people a way to at least navigate through it quickly with samples that they can leverage and modify of things. I think they'll speak to the right audience. So try to understand who you try to speak to, rather than you're not trying to speak to somebody who's writing the low-level plumbing when they're trying to use it, versus vice versa. So you'll oversimplify over the complex. Make it simply over the complex. Separation of concerns, you know, think about it. We'll think about it as well. So maybe what I'll do, I'll take the guidelines for extending and I'll add the links to the repos I created. I'll add some more readme. I have people who can look at it and we can have an online discussion rather than having it here, unless somebody wants to talk about it here. Sounds good. I would need some help. I don't really understand how to create the endpoints. I'm trying to create endpoints, but not creating NSM endpoints. A little bit opaque to me what the YAML files would look like. Oh, okay, okay, that makes sense. So I know that we had a network service and sort of a dummy network service endpoint example. I presume that you've looked at that and found that to be less clearly you would like. Yes. So Sergio created that simple data plane. If we could create a couple of YAML files for that so that we could use, maybe a little bit advance and ping Tom, but like a web NGX server to talking to a REST API and then using the simple data plane as a transport. How would I set that up? Okay, cool, cool. Because then we'll have a complete end to end application that people can say, oh, look, here I can use... It becomes our hello world, basically. Yeah, and then if I build a different data plane, I can use the same example and plug it in. And I say, look, I can swap out data planes and use the same example. And I think that starts to show the power of NSM or some of the features. Oh yeah, and I can swap out data planes and get the same example. Oh, look, I can swap out the network service endpoint implementation. And I still get something that does its thing. Yeah, I think that's a good idea. Yeah, I agree with that data plane transparency. That's something we haven't had in other endeavors. I mean, like Neutron, for example, even ODL doesn't quite have everything for data plane transparency in the release yet for, because it doesn't have the southbound for net com for really quite in there yet. And certainly being nice to have it in this platform. Yeah, I think we actually have to have it in this platform because among other things, we're gonna find different people in our needs. For example, we're gonna have people who want something that just works. They don't want to do a whole lot. They don't really care a lot about performance or latency. And for those people, a simple data plane probably works great. And then you'll get people who care a lot about those things. And for those people that want a more sophisticated data plane and so welding any single data plane is probably not a good thing. One other thing I think we will find is that we actually have different classes of data planes in the system. So there is the sort of local data plane need to sort of, I've got a local point to point data plane that connects two containers locally. That's one kind of data plane. You've got what I would call sort of the hardware data plane which is I have an SRIOV or hardware NIC that I want to provide my network service. That's a little bit different. And then you've got the remote data plane which is the, I want to reach a pod and it's not here. And I think those data planes may in fact being able to plug those separately may be quite interesting. Yep. I think once you start having examples that makes it, we can actually test ourselves to make sure that we can actually do these things. Agreed. Agreed. So, it's gonna be interesting. Hang on. I did want to bring up, I was trying to find my mute button. Yeah, definitely, stop laughing. A concrete example is definitely good because I want to play with the data plane but sometimes I just can't think of a good scenario to test out just to prove it out. So, having concrete example to say, hey, I want to connect this to that and be able to do X, Y, Z is just so much help to be able to get in and use it with just a concrete example that you can then extend to how you want to use it later on. Well, the Sergey's simple data plane kind of starts that. It's, you know, but we need to extend that. So, in the interest of time because we have some pretty big items on the agenda. So, I'm gonna wrap up real quick with this part. So, just to finish up by SROV, I don't think we've had much movement on the packet.net side for this particular week. So, that's something that we're gonna have to work out. You know, do we want to see if we can find a way to experiment with them or see if we can get a reserve device and work out like which type of reserve device will we like. There's some logistics we have to cover on that side before we can really test that assumption that it really is the BIOS issue. And so, in terms of, so in terms of going back to the main agenda, one of the things that we have to do is we have very little time for the open source summit arrives. And I wanna make sure that we have enough built up for documentation's approachability so that we can really drive people who are interested in the community to help participate in these particular meetings. And I saw that Kyle has made the first step towards building a landing page. Is that correct? Yeah, in fact, I can quickly share it. I mean, right now it's, I mean, I'm still working on it, so it's just local, but I'm happy to give everyone a preview if they'd like. Yeah, if you can bring it up and I'll talk a little bit more while you're getting that set up a little bit. So... Hey, Tom, if you could stop sharing for a second, I'll just quickly share the website then. Cool, okay, go ahead, I'll bring it up. So a couple of other things as well is I think it would be very good for us to have someone who is present who is willing to take notes on some of the types of questions that are asked. So in other words, if there's something interesting that comes up that looks like Network Service Meshes would be well suited for, someone asks a very specific question that we may not have the answer there, being able to capture that information. And then we can work afterwards and get it back onto the landing page with this new content. So that way that it becomes this, it's something like it always bothers me, like you go into a conference and someone asks a question, it says, well, I'll get back to you except that connection never happens. And this actually shows a level of commitment that yes, we do wanna get back, we do want to engage and we want to be active about doing so. And so I think if we were to go with... Something like that, I think that that would help drive attention towards us as well. Not to mention it would also help us for our own records and for our own information as to work out what type of questions people are asking. So the next time we hear that question, we all know the answer. Yep. I mean, the other thing that I'll point out is I will have 20 minutes to talk about Network Service Meshes at the seminar. And one of the things that I tend to do is put up QR codes that point to things that you want people to link to. So I will definitely be able to put up a QR code for folks to reach this page, which you'll people tend to take the photo with their phone and then they can reach the page. Just a little something, make sure the landing page itself has a QR code on it that points to itself because we can pull it up and people can take photos of the front page. Yes. Yep. And so I think like we need to work out this week what information we want to put on this landing page, like what scenarios we want to discuss and copy over some of the data from the repository into a web format in this scenario, which should be pretty easy because most of our stuff is marked down. So... Yes. So it should integrate nicely. But yeah, sorry, go on. I was gonna say one thing I was thinking that we should do this week is, I was planning to push this out as a new repository, a new Git repository, the website basically. And then what I was hoping we could do, we can iterate that way this week on it before we end up, excuse me, the coming week, before we end up pushing it live at the end of next week because that way everything's pull requests, right? Then we can have it build that way. We can comment that way. What do you all think of that? No, that sounds good to me. Yeah, I agree with that. And so we don't have to work out right now what exactly should be on that. I think we should rally on IRC and rally around the repository and pull requests. So if this isn't already on GitHub, if we can create a repository that, I have a network service mesh group and one option is we could land it in there. And that means that we don't have to give people access to the main repo, but we can add people to that in order to organize in the content. So that's one place where we could potentially live. To start off with. But the main point is that we need to have a repo that people can send their pull requests to and that we can give people access to. And I think it should be okay to preempt some of the questions as well that we expect people to see. We know that certain people ask certain questions often so we should seed the page with those facts. Yep, I agree totally. I've got one more meeting after this one but then the rest of my afternoon is free and this is what I'm gonna focus on. So I'll have this pushed out in some form today at least. And then we can all iterate about how bad a designer I am and things like that, which is, you know. Although I will say I'm pretty happy with this Hugo theme actually. Once I show you this it's pretty cool and we can change whatever we want. I mean, I just went through and picked images for now for different places, but yeah. So I'll let you go off and show off the site and then we still have other things to get to after that. So we'll. Yeah, yeah, let's, because we're gonna push this out as a give repository, let's just spend no more than five minutes on this so we can still cover the rest of the agenda. Cause I could see us totally, you know, spending the next 30 minutes on this. So what I did for now, I'll just, I'll just highlight some things, right? So I had to put the spider up here as Ed was mentioning to me for now. For now I just put, you know, a home link which obviously goes back here, a link to the source or doctor images. If we want to have a blog and then I was gonna give a landing page for the open source summit as well where we could put a bunch of collateral and things there. This just has essentially a quick rundown, super quick. I like how this slides. So then I have our problem statement next and Fred, thanks for the document. I took a lot of this right from the document that's merged in the tree. I would Smith a few parts to make it fit a little better. So it just has essentially the problem statement. Then we go into a little bit more detail on what exactly this is with a link to our documentation in the GitHub repository for now as well. And then on the end, I kind of put in a little blurb about the path to cloud native NFE. Ignore the bottom for now. I haven't gotten to this yet, but roughly that's it. So, and we're free to iterate on what we, you know, like Frederick was talking about, we're free to iterate on what we want to put on the top here as well and things like that. But I really like the way this theme for Hugo kind of flows. I think it's pretty cool. I think it's good. I think this is an excellent place to start. One thing I would suggest that we do think about and, you know, is making sure to broaden some of this, brought a little bit more than just NFE. We absolutely do crucial things for NFE, but there are a lot of enterprises in case this is going to be really quite amazing as well. Oh yeah, absolutely. And in fact, we can, I know that currently our documentation is totally on that, but for example, we can add additional bars down here that talk about the enterprise use cases and things like that as well. So, definitely, I agree. Also, what about TAB for use cases? Maybe. Yep, totally. And exactly, and I agree. And, you know, we definitely need more TABs and the use case thing and stuff like that. I don't think more TABs is a good thing. One thing I would suggest that we actually look at is if you look around at a lot of other sort of more modern projects, there are certain kinds of things that start to emerge as patterns where they'll have like a good one for this is, actually that's no longer good. So people will often have like TABs that are like concepts, documentation. Yes. Getting, you know, there's a pattern that's kind of emerging that's sort of like, what the fuck is it? Where's the documentation? How the fuck do I do something? Yep, yep, yep, definitely. So, and I've been looking at some of those, some of those as well, definitely. So this is, and definitely once we get this pushed out, we can all as a community iterate next week by pushing patches to this website and tinkering with it until we get it to the point where we're pretty happy. And I definitely expect we will continue to iterate on it even after the open source summit. But the goal next week should be to just get something that we're happy with, you know, for that Tuesday event in Vancouver. I think also having the types of users, so people who come there, you know, do I want to develop network service mesh? Do I want to add to network service? Do I want to use it? So there's different paths for them. Yep, no, they're absolutely, there absolutely is. And I think that's going to be crucially important because, you know, the way that somebody, like if you look at the stories that I saw this as good as the stories, if you're looking, if you're somebody who's developing an app, you have a totally different view of the world than if you're the guy who is sweating over what all goes into secure internet connectivity, for example, right? And you actually don't want to know about each other's worlds very much. Yeah, yep, cool. Well, I will stop sharing now. I've used exactly the five minutes I had suggested I should use. I'll let Tom go ahead and share the agenda again and we can keep going. Thanks. So before we share the agenda, and Hannah and the hardware next year, do you want to show that off? You might be on mute or I might be on mute. No, I'm on mute. It's the theme of the day. I'm on mute. I was on mute. I say much more intelligent things when I'm on mute though. No, my suggestion would be that we do the following. We kind of balance that to the end. So that we have time at the end, I'd be happy to walk through it. But we have other business I think we also need to get to. OK, I've bounced to the end then. Ninja, agenda bashing. But the link is there. This is actually the story that I told resource management this week about managing hardware next. OK, so group to test out Dependabot. So I personally think Dependabot's been doing a pretty good job. We found that one area where it didn't upgrade properly, Kyle fixed that up. So overall, I'm pretty happy about it. Anyone want to talk about their experiences with Dependabot in the past week? It appears to be the Pendle. That's why it's called Dependabot. So the one area that I think that is not as well, when the error occurred, because we did have one problem where it couldn't upgrade dependencies properly, did Dependabot open a pull request or an issue saying that it couldn't upgrade? Or did you have to go to the dashboard in order to see that it wasn't working anymore? It was something on the dashboard. And it's not, so that was the problem. They do note that I forget if the Golang support is either alpha or beta. But I remember they did note that Golang was somewhat recent compared to some of the other dependencies for languages. So that might be part of the problem. But that was, you're right, that was mildly annoying that I had to go just look there. And there wasn't a ton of information. However, that being said, this is a completely free service that we're using. So there is that as well. The other thing that I really like about the Dependabot though is that the source code for it is for the actual bot is completely open source. So if we ever did hit issues or anything, we should be able to look at the source. Should we so choose? And in theory, we could actually run our own version of the bot hosted somewhere else if we wanted as well. So that's the other reason I kind of like it, because at least those options are available to us. OK, that's good to know. So if it ever becomes onerous where we have to keep looking at this dashboard or work out if these problems have occurred, then one option that we have then is to modify the code to do one of two things. We can either have it create an issue when such a problem occurs and block creating new issues until it's resolved. And the second thing we could do is create a label that talks about Buildabot's own health. Sort of like, yes, this thing is passing its CI. It can have a Buildabot requires attention label. Exactly. And so we hop onto the front of the web page enough that when we hop on, if we see it's red, then we know we need to hop on it and deal with it. So Ed has been working on redrafting the email which is going to be sent off to the working group for the network service mesh. So you have the floor. Yeah, so I've got a lot of input. I've been trying to sit down and do a redraft. I have not yet sat down and done a redraft. It's been kind of a very meeting heavy week for me. And so I have not actually done that redraft. But it's become really clear. It needs to get a lot shorter, a lot punchier, and very focused on goals. And for the purposes of the working group, those goals need to be basically about clearly documenting the things that go into network service mesh. So basically how do people, basically how the architect, our document in the architecture, documenting the APIs for the people and things that actually plug into it and so forth. And I think this will eventually end up being quite crucial because we are going to want to have people who want to do things like external network service managers or proxy network service managers that plug into the system will have people who are wanting to plug in data planes and so forth. So we'll definitely need to get that redrafted, but have not yet. Okay, so yeah, if you need any help with it, definitely let me know. And I'm pretty sure there's other people here who would love to contribute. So. Quite frankly, anyone who wants to actually take a pen, I'm happy to grant edit rights to the document. And I think several of you already have them. So I mean, the lovely thing about Google Docs is the key history. So nothing is truly lost. So please don't feel like I'm sitting on this work item. So for the draft X Factor CNF, I've been thinking a lot about what such a thing should look like. So this week I'm going to have my first crack not on the heuristics themselves, but based on what Tom suggested, which is to just start working on the overall goals. And so what I'll do is I'll post a message when I've done the first draft of this. I'll post a message to the email list and ask for collaboration on this. And so I'm not expecting that we come up with any set of heuristics by the time that Open Source Summit comes out. But I do think that trying to capture exactly what it is that we like, what do we want the world to look like ourselves? Like what properties do we find important? And once we have those, then what we can do is create the set of heuristics, describe like, no, you want horizontal scalability. This is what you should look at. You should look at how do the 12-factor apps work? How does Kubernetes horizontal scaling work? And what's required for your application to like what properties your application should have? And I think what's going to end up happening is that we're going to have people who have different sets of dates. They're not going to have the needs for everything, for all of those goals. But if you have a need for, your data plane needs to be fast, cannot have any intermediaries because of the performance requirements, and it needs to be horizontally scalable, then it's like they can look at the various heuristics and just learn from it. And then that'll help them make better design decisions as they move forward. So that's sort of like the pattern that I'm thinking of at this point because I think there's too many ways, too many types of things that we're talking about that until we have a very solid definition of what a CNF even is, which we haven't even gone to yet in the community, then, you know, you're saying, hey, here's the heuristics to create them doesn't make as much sense. But saying these are the type of goals that people care about, I think can help drive some of the conversation in that space. Does that make sense? I think that makes total sense. Cool. So I'll have something on that soonish. Let's see, I mentioned before, I don't think anyone did anything with the SROV this particular week because we've been focusing on other things. So, although there was something on Taylor with reaching up to Jacob, so was there any movement on that? I don't know, do you happen to know Watson? I actually know that I text him, but he hasn't responded. That's okay, that's okay, he's off today. I do know that I did actually dig up in the course of talking to Sergey. So there is two interesting things came up. One is there is a list of which mix or with which flavor at packet. And so that actually is helpful. The second thing that I dug up is the availability of flavors varies radically by site in packet. And so one of the issues that we were having was the only flavor that was available in the Canadian site that was where Sergey was trying to work was not a particularly helpful flavor in terms of getting the stuff working. And we discovered, for example, their San Jose site and of all odd things, their Newark site have the broadest variety of flavors available. And so it becomes easier to figure out which mix you want to use and so forth. I understand there's San Jose site, but I'm really confused by their Newark site. I mean, what server wants to go to Newark? Yeah, just to be clear. So packet ed, not to be confused with the one and only ed is mentioned that there's no, that even in the site, there may be variants in hardware configuration. So I don't think we can rely, like even that document doesn't fully coincide with the information that I was told about how you can pick an instance and end up with potentially a different card. So that's something we should be careful with. We'll have to figure out how to work with them so on that and sort of see what can be done because you do actually want, if some people do want to be able to try and actually run this stuff, and I think bare metal public cloud is gonna be important for a lot of consumers that we would have for SRIOV. And if you're running bare metal public cloud, you damn well need to get what you expect in that area. Completely agree. And I also think that what we should do is we should work, try to work out who the right person is who controls that particular decision and see if we can convince them to flip that decision around and say, look, you want to tackle these particular groups and then it appears that you've mentioned you want to head off in this direction. And if that's true, then you really need to enable this feature and take a look at it. Yeah, I mean, it's, I mean, like all it really needs to be is there's some way of getting a deterministic result. If you need a deterministic result, right? If they could literally just give you a little checkbox that says you were guaranteed the advertised NIC when you select the flavor, they can still have diversity in their underlying hardware because you're working all of that out as hard and expensive. But if I click XYZ flavor and it's supposed to have ABCNIC and I click the little checkbox, I'm damn well gonna get ABCNIC. I imagine people would be even willing to pay a slight premium for it. Yeah, so let's work out what we want to tell them and see if we can convince, like work out to that person as we need to talk to and see if we can convince them that that's an important feature. And if it's on their roadmap, it's something that they have to do. And if they haven't added it to their agenda or task to perform, then that'll be good feedback for them. Okay, so we don't have too much time, so let's talk about the extending network service mesh and whether it should be in or out of a tree. I think we're discussing earlier. So I mean, why don't we just go through that action item I had on the to-do board? Could you follow the link to the action items Thomas? Yeah, sure. Sorry. Where are we? Issues. It's towards the top. Oh, yeah. I think I already have that out, but anyway, a little bit of redundancy in my way and my pages is fine. Okay, we're looking at the... Each review, guidelines for extending out of time. I also had to do there under the last, the second from last bottom to do, I had a, or something separate, but separation concerns and different audiences. Separate out the concerns for the audience, MSM to make it more accessible. Come on. Oh, that comes up in a different page, the way it's coming there. Should I stop this one? Where'd it go? Are we just looking at the pull request at this point or? Yeah, I would just leave it now and let's focus in the pull request that needs a review. Yeah, pull request 180. Oh, yeah. 247. 247, yeah, that's over here. Okay. So let me add the link to the new repo I created with the template generator stuff and have a discussion there. I mean, Kyle, you're the one who had comments and I mean, I'm not sure which way is the best way to do this, but I'm open. Yeah, I mean, and by the way, thanks for doing this work. I spent a bunch of time reviewing this and it's really excellent work, so. My main comments were, in fact, I was the one who brought up the in tree versus out of tree. And the reason that came up actually, John, was when I was reviewing it, the directory structure you had, I was confused at first because it didn't match what we had in the network service mesh repository. But then it made sense to me when you indicated that you were kind of thinking of almost a clean slate out of tree, what the directory structure would look like. And from that perspective, it made sense. And that was why I said, well, we should probably spend some time discussing with the broader community. Do we want to do out of tree or in tree for these things? So what I did was, it took you out of tree idea. I wrote a script that basically uses the work search you had done and just pulled a bunch of the existing make files and stuff, and created an out of tree template structure. So now you can basically run a script and I'll create an out of tree NSM for you to go and do your own work. And then you can do a build against the old link to the NSM main repo to basically create a separate. Plug in for you. So I mean, in terms of the out of tree question, I think there are two really crucial points that we have to make sure we do no matter what we decide. And the two really crucial points are number one, we need to remain welcoming, meaning that for reasonable-ish kinds of things, we are welcoming to having an appropriate place to put them in tree. And number two, we have to remain flexible, meaning it should be possible to do work out of tree if for any reason you decide that you want to work out of tree. As long as you do everything else is gravy. Definitely. And I will indicate that past experience, years back in neutron, in tree for things got complicated just because we had the other thing. So that got unwieldy at that point. Now, I don't know, do most CNI plugins, for example, live out of tree or is there a central or how does that work? They mostly live out of tree. And so I guess the thing I want to be careful about is I want to be avoid the appearance of there being the one true data plane. But at the same time, we have to do some data playing work in tree just to get shit done, right? And so I don't want, I agree with you that you can get out of hand at some point. If we do get out of hand, then we have to sort of figure out how we're gonna handle that reasonably. But we're far from the day of getting out of hand. So I think we need to remain vigilant about getting out of hand, but I wouldn't want someone to come and look at network service mesh and say, for example, oh, that's only if you're using VPP. Yeah, I think we need in tree, they extend on Sergey's examples for in tree work for some of the popular data planes that people in the open source world, like for example, open V-switch and VPP and then maybe a few others. But certainly there'll be people who want to work with proprietary data planes or fork their own in anticipation of doing something open source later or whatever corporate agendas and they're welcome to do that. The other thing I want to be careful with as well is that if someone's trying to do something in tree, then that means that someone from, we either have to give those communities commit access to merging their own stuff, which gives commit access to much more. Or we have to, we end up being the gatekeepers on an area where we really shouldn't be the gatekeepers. And so I think we should be very careful with in tree from that respect. Like right now it's probably okay, but in the long run, like even the sample data plane, I would argue that we should eventually push them all into their own repositories that people can... Yeah, at some point, I doubt if we're quite ready for that. It seems like if you did, if you pushed a bit to too many different places too soon, then people would just have trouble keeping track of all of them and finding them. Yeah, problem just now is that, I mean, I had to do some detective work to figure out what all the files were for creating a sample data plane and where they were in the tree. And that's why I created my own template tree. So it took me a day of futzing around to get it right. So if everybody's had to spend a day, well, I knew my way around a little bit already. So I mean, Emily coming in blind who says, oh, I want to jump in and create a sample data plane. It's going to be a steep learning curve and they are going to push stuff in, just pull you in a clobber of other stuff because even to make files, Sergey edited the main make files and the Docker files to make it all work. So to create the way that's why I confused Kyle by creating a different directory structure for the samples so that we don't... So people creating samples don't have to touch the same files as the core infrastructure, which would also cause a lot of problems because you know... Well, I assume that and I'm aware of that because I tried to do some of the same thing. I took all the sample data plane code, tried to figure out where it all was and got to that point. And it is a little bit complicated because there's a lot of files in different places. So I, but that's useful. I figured that once you followed what you were talking about, John, and then people, if that data, if that thing were to be put in a pull request and they put it all back to a fork or something and then put it in a pull request, that's the workflow that I envisioned in my head for what I was gonna do. Yeah, but I put it where it was convenient to do the development and then put it back and then test it before I did the pull request. I don't know. I mean, that's just my own peculiar way of doing things, but it kind of made sense. I don't know whether early in the development phase quite justify sort of creating public repos of this stuff spread all over the place. I'm just worried people wouldn't be able to find it and might detract from the usefulness or whatever or degree of open source, what do you call it? Review that different ones have got whatever different governance roles. It could get, I think I have a certain amount of it in this project is probably a good idea for a while. I'm not questioning people's way of, and I think that's separate from what workflow you use as an individual developer in your own space, fork, whatever you're gonna do, you know, but at some point, when you get ready for a pull request, we should converge on something for at least for the first four, five, six, maybe they go back in here. I don't know, it's just my thought, just to keep things kind of consistent and in-house for a while and then let whatever happens, happens after that. Just a question of when? Yeah, I think something we can do that'll help in the future as well is, you know, if we identify where, what files are, where necessary that have been scattered around and so on. We can start to structure the code base in such a way that this becomes an easier process. And worst, well, one potential path towards this as well is we could potentially expose out some form of an API or something similar and use some, you know, we can use some form of leaves hooks or something similar that knows how to abstract a lot of this away. So that way that it really becomes very easy for a developer to type in the code in the appropriate sections and get the results that they're expecting. And so, you know, so I think that, you know, we should see like of the first few data planes or the first few integrations to see like how that works and how that goes. And then once we understand what people were really, what problems people were really having and how network service mesh itself is also growing, then we can start to look at such an abstraction. If you take a look at what I did, I'll post it. I did essentially what you're talking about Fred in that I created a tree that had all the files for sample data plane and cut down to make files that only built the sample data plane. So that could be in tree or out of tree. So I think it makes the, it kind of solves both problems. So you could do it in tree if you wanted and you could do it out of tree if you want to. There's no restriction. It allows people to, you know, do a pull as Fred said, you know, as Tom said, bring it to a pull request and then, you know, push it back in again. And then we're fairly confident that that pull and that change request is only just touching the sample code that won't touch anything else, which makes reviewing it a lot easier. Cool. So we've hit the top of the hour. If you can do one thing for me as a, if you can add in a GitHub issue, talking about providing an easier way for these integrations to work, just, you know, it doesn't have to be code or anything, just say, just so that we have something tracking this. And in terms of Hannah and the hardware Knicks, there's a link on the agenda and if we have time, we can cover it next week in more detail and people can have, that would give you time to look at it and ingest it and then bring your questions so that that way we can improve the narrative. Will that work for you, Ed? It is triple muted again, Ben. Yep, that works for me. Cool, yeah. And I'm really excited about Hannah and the hardware Knicks. I'm a little sad that we ran out of time, but. I'm really amused that I appear to be writing highly technical children stories. I think it's effective. So, let's look at that. And if you want to hear the presentation, there's now a link to the video where I presented it for resource management, so. Great, and with that, we'll close up the meeting and thank you everyone for attending and we'll see you again next week. Bye everybody.