 Hi, how are you? Hey, can you guys hear me? Hello? Hey, hi. Yeah, yeah. All right, awesome. All right. Apologies. Normally I try and get here five minutes early since the meetings are not starting with the host anymore. But I had one. What? Hey, nice. Hey. Welcome. A few minutes for folks to turn up. So Frederick is coming. Okay, let's go ahead and get going. Let me go ahead and share off. Well, first of all, before we start walking the board. Talk to me about the things that you guys need help with. What are you working on? How can I be of assistance? How can we work together? Hmm. I think at the moment there is no help actually required. Probably just. Denise is waiting for a document. I know, I know. Solution for wheel three. But. Yeah. Yeah. Yeah. I have plenty of work. Which needs to be done. In areas of open policy. Our garden so on. Excellent. Okay. That's good to know. Have a day. How are you? Still waking up, but doing well. How are you doing? So the question Andre on the, on the network service manager stuff. I know that you're starting with the device plugin version rather than the callback version. I was just kind of curious why. Yeah. I've not yet added the cool back stuff. Here's my general attitude, right? Which is, I know we have this weird, racy thing that's shown up in CI that's hard to reproduce. Right. But the callback approach looks much better to me than the device plugin approach. Quite frankly. Yeah. Actually, at the moment I wanted for both. Device plugin and the callback. To be unified in one code base. So it's just possible to start using both variants. So, I mean, you would like to have it. Yeah. My gut sense is that's right, which is that the callback stuff can work and it certainly looks quite reasonable. It also looks very, very nice and easy to use. And there are a few questions. I've got a big, a lot in my own head about being able to properly get the identity of your peer, but it looks fully resolvable to me. I just haven't got the immediate set of code in hand. But if we can get that stuff sorted out, I would kind of frankly almost prefer just doing the callback from the network service manager and move the device pluggy bits for MIF down to the forwarders. Does that make sense? Yeah. Yeah. Yeah. I will update my PR with a callback with one single entry point for an S manager. Optionally, if user will use a device plugin, it will be additionally allocate workspace for use with and so on. So question, what is the advantage to supporting the device plugin if the callback is working? To have MIMEF interfaces to be also supported. But if callback is working, then MIMEF would probably be more properly something that came from the order. Since it would be the one that would deal with it. Yeah. Cause I'm also thinking in terms of sort of like simplicity of the code base and also the dependencies involved. Cause the network service manager is using callback. Then basically it's, you know, that it's a pretty light thing. It doesn't actually need to bring in any of the Kubernetes dependencies into network service manager. Yeah. Yeah. I agree. So, and one of the things like that I keep running in my head is I, when things become too large and when the extent of a single thing becomes too large, when the single thing tries to do too much, its dependencies will almost inevitably blow it out. And so I keep an eye on dependency scale of the thing, not because it's good or bad intrinsically, because you can have things that are very good with very broad dependencies and things that are very bad with very narrow dependencies, but something that has a huge number of the more as the dependencies grow, the probability that you have scope creeped beyond a good idea is, does that make sense? Yeah. Yeah. Yeah. Great. You know, and it doesn't, like I said, it doesn't, there are really a lot of exceptions to this rule in both directions. So it's not a thumbs up, thumbs down. It's a probability thing. I tend to think of rules of thumb for me as things, having to do with probability rather than certainty. Right. So if you're, if you're doing X, the probability of Y is much higher. It's literally the way I think of my rules of thumb. Yeah. Yeah. Okay. Cool. Probably. Does that also send to the rest of you? The moving towards having the callback, um, using the callback stuff for the network service manager and then moving the MIF, the device plugin stuff to MIF. To the border. Yeah, I think. I think that definitely sad. I need to take a little bit more through Senator, some of the implications, but it sounds like it's a good idea. Cool. Yeah. Okay. Awesome. Nice. It is. Okay. Fine. Oh, I have one question. Um, related to well, three NC. Um, here I don't quite understand where we should start work on well, three in the sea. Uh, because we have two entry points. For example, is the K repository and one area per repository. And, uh, as I understand, uh, at when start work, uh, uh, uh, on. Yeah. Yeah. And Frederick when start, uh, in, uh, is the K repository. Yeah. So I think actually it's. You got us. You got a strange answer that sounds like Frederick and I disagree because the nature of the question that was asked. Um, I think that's a good question. Um, I think that's a good question. Right. Because your question is very rational. Where should I start this? Um, and the place that I went to, and the, your, your first suggestion was let's go lift and shift the internet main work. And the internet main work is going to have to be subtler. It works, not just lifted and shifted. Uh, as we move the SDK. And so I'm actually wholeheartedly in favor of starting the BL three work in the SDK. And then we'll move it to various pieces that we don't want to move. Does that make sense? Oh, yep. Uh, does that, does that make sense to you, Frederick? Does that line up with your feelings? Yeah. My concern with the, with is landing in the Edison. Mono repo first is that it'll end up with. Uh, a very strong dependence set of dependencies to that repo. And then we'll have to redo everything again to get it to land it back into the SDK. And I think we're close. You have exactly the mirror image of my concern in the other direction. Exactly. And I think that the SDK is far enough and long now that we can safely start building on it. There's one last part that I'm working with on the ICMP responder for the SDK that's built on the SDK, which is I just need to get that connection working between the network surface endpoint and the NSM manager so that we can communicate over the socket. And once we get that part done, and then I think it should be trivial getting the rest of the system up and running. For Artyom, he's in progress with a wire guard. He's trying to implement, move the implementation of the wire guard handshake into a protocol, into a plugin he already had. So probably, I hope in one or two weeks, we'll have a handshake working and we'll move to the security to be implemented in plugin. And for Dmitry Sergei, Dmitry is working on SRIOV stuff. So we're putting all together and working on document to describe use cases and how we see it should work. So after it, we could discuss with you guys. Probably we could share or start another meeting to discuss how it should be. After understanding, we will be more deep. And we have some specs regarding open policy agent examples. So guys plan to share with specs as soon as possible, probably in the next few days. It's more interesting when I unmute myself before I speak. No, that actually sounds fantastic. Cool. So it sounds like things are more or less going smoothly. Is there anything that, other than the noted, if they issue MVL-free, is there anything that folks need in terms of assistance guidance, Pierre, I'll walk through, et cetera? Yeah, if you have any documents describing SRIOV, it'll be good if you could share with us. Ah, thank you. I appreciate the reminder. I'll go through there. So a whole bunch of stuff that's been written on the SRIOV stuff that I can go send you links to. Yeah, this will be helpful. Also, we already discussed, if you want to slack a bit, I'm trying to unify the building and the testing approach for all same applications like Forward Air or NS Manager. And plan to push initial things into my pull request today, so we'll share pull request if it. Cool. So from our side at the moment. Cool. Guys, do you have any other questions? Miss, on my side, I have provided two PRs to SDK repository. They are ready for review, so please take a look. Also, I went to fix one bug related to floating inter-domain related to monorepo. I have provided a link to the issue you can take a look. Cool. We'll definitely do that. One other thing I do want to comment on, which is I do appreciate the proactive way in which people are picking up issues and bugs related to the stuff in the monorepo. Part of what gives us the space in terms of interest to do this refactor is that we have a really solid code base to begin with in the monorepo. We're just modularizing it, improving the various things so we can bring some more advanced features through the modularization effort. And the world is very patient with that, given that it's a really solid code base. I mean, I had some people who wandered up to me and said, hey, yeah, we looked at this. And we were really kind of shocked, because we went and got the code base and it just worked. And it did what you said it was going to do. And so that's very good. And the fact that we're very responsive to all the people who are kicking the tires is also incredibly important. Very much appreciated. Anything else before we conclude for today, and then we'll reconvene at the next call? Yeah, sounds good. All right, talk to you later.