 How are you? Very well, thank you. So we'll give it a couple of minutes for folks to turn up. Does someone would someone like to share the issue board? Thank you. Much appreciated. Okay. Shall we get going? Yep. Cool. So starting over on the going left to right, because normally you move cards right to left. So if you start left to right, you don't end up having to do the same thing twice. So looks like we've got a, why are there mechanisms PR open here, Denise? I know you and I have been convincing back and forth about this. Is there any he'd like to say about it here, or I would encourage more folks to get involved in the conversation. Oh, yes. I've faced it with some problems and I have described this problems into PR. Cool. I think this is the PR to the API repo though. Oh, yep. I've started to migrate a wire guard mechanism into split repo. Well, that's excellent. API conversations are tend to be a lot crisper than others. So this is good. This is definitely good. Cool. I was muted. Awesome. And then we've got create network service registry client, a pod name, name cluster name, links to registration. Has that, I feel like that one has gone in. Am I misremembering? Yep. I'm already budget. Okay. Cool. So I'll go ahead and close that. Thank you very much. Sergey. I make sure I'm not confused. People who have fun, give up names. I sometimes get them confused at first. Yeah. Yeah. And just in general, by the way, Sergey, thank you so much. You've been doing a lot of small pushing up tests for things that have been just awesome. All right. So move, plug into core DNS repo. Denise, how is that going? I know that's a different repo entirely, but. Oh, this is still under review on coordinates site guys from coordinates. Very slow review. I have responded all their comments. And I think we should wait for new feedback from their site. Let's keep an eye on it. Sometimes people just get busy and get distracted. So if it goes too much longer without them responding, we may need to poke them in some way. So, but that seems to be going very well. Cool. So moving on into in progress. Do you want to talk more generically about the wire guard stuff, Denise? You mean wire guard for the agent for the issue? Yes. Yes. For this issue, I have provided two PRs with two potential solutions. The first pair with number 2110, this pair. You can open this pair if you go into the issue. Yes. The first PR 2110. This PR provides a solution with adding simple L2R frame as adapter. In short, it allows using L2R traffic for wire guard device. And this solution must have all tests. Do you have some trick? Oh, yes. It is a trick. I just wrap an interface for tune of wire guard device. I see you recall that you have a really good diagram somewhere for that. But yes, I'm sure if it's here. Can you search tune.go? That's it. Let's talk about the diagram. In short, it just adds IP header into any receiver's packet. And on the receiver side, we just remove this IP header. And it is working. But it looks like a trick, but can be used for a temp solution. Maybe we can make it as environment variable configurable. We can. Also, I have provided second PR. This PR provides an alternative solution with the agent via level three cross connects. And with this PR, I face it with an expected problem. I have described the problem into comments. Comments of PR? Yes. And the main problem is that wire guard device receives wrong packets from Mimiv interface. And I think to figure out this problem, I need to run a more small example with L3 cross connects. And I tried to fit some examples, but I did not fit. That's why I have asked about examples. Did you have a chance to find a forum? Yes. I have asked guys from VPP agents their forum. And I just read their feedback. Okay. Also have a look and see what you should have running up against. It turns out sometimes actually having fairly serious network chops gives you hints of the kinds of things they could go wrong. Cool. Anything else on wire guard? Also PR changes for kernel forwarder is ready to merge. Cool. Any way to add it here in projects? Yeah. You should be able to add it to the projects here. It is here. You can just move to the second issue. It has the second name. Yes. Yes. And you can take a look at the PR. Okay. I think it could be merged. Most of you guys already pushed. Yeah. Okay. Nice. I think we have a question here about switching to the new version of the VPP agent. It is also prepared a pull request with it. And it has just few tests failed so I can check to log in true whites. Yeah. Do you have a chance why VPP tests are failed? Oh, yes. Sure. I didn't look at this because I just provided this for testing wire guard stuff is level three cross connects. Should we move our report to using VPP agent version three? If it's used to work. Yes. It's got several things that are actually fixed it. And it varies in several areas. One of the things that frankly is I tend to like things that are nice and clean. And one of the things that it actually fixes is you no longer need the replaced line. The Satori stuff in VPP, these three dot zero dot one, which makes me super happy because that's just really annoying. Um, so yeah, I mean, if it passes tests, I would actually look at that. Okay. We will check in this case. Why we, we're not going to do that. Yeah. And if there's actually a legitimate problem, then we want to get that back to them sooner rather than later. Yeah. All right. So, um, awesome. So let's see the, um, monitor stuff. How is that going? Andre. Uh, I'm mostly ready with it. Just trying to make a good testing solution. For such network. For such chain elements. Uh, as a temporary solution, I use, uh, switch to a new API for our entire network service mesh repo. So, I, I, I, I don't follow how that's related. So for the, the monitor chain element stuff to go into SDK, I don't see how that's related to, uh, anything in the monitor repo. I know. Uh, I mean, to use the, our monorepo as a testing. Bad. Uh, to some of the chain elements. Uh, because, uh, without a real tests, like integration tests for a VP, VP, VP agent. It's actually, uh, hard to test some parts of functionality. For example, uh, in case of the metrics, I just need to connect to real VP agent to be sure if all interface names are much it and so on. Okay. Now that's actually that, that does get to be true. We get to the level of integration. No question. Um, but one of the other nice things about, uh, the VP P, uh, 3.0.1 when we make that switch, um, is that, um, and we should probably switch the SDK VP agent sooner rather than later. And it's probably simpler there. Um, is that, um, it uses the GRPC client connection interface rather than GRPC client connection, which means that you can literally mock the whole thing out for unit testing. Yeah. Yeah. Um, which, which that makes me so happy. It's almost impossible to do that. Um, so, um, you may also want to take a look at some of the things that have been landing in the last week in terms of, uh, sort of the style of testing of things. There's been a lot of various things that make certain kinds of testing very, very simple. Um, yeah, I've seen some, some of the stuff. And as some concerns. Um, I think Sergei used a similar approach as you, uh, meant into his decay to some of the China elements. And, uh, I think he prepared a pull request with the context. Uh, check. Let me check. So simplify it a bit. Uh, and use it. Uh, check. Let me check. So simplify it a bit. Uh, and use it. Uh, so again, did you remember which, which one you use? Uh, we wanted to use to pass some special context. Instead of having some, uh, assertions inside of the chain itself, just to feel a context with our values. I'm sure if it's in this pull request or not. And do assertions right after we do a request. Yeah, because then you can tell the individual piece is actually doing its job. Um, now when you go to integration, you need to sign. The piece needed to do a slightly different job and come back and fix that. Um, but there's also been a bunch of stuff that makes a lot of that easier. Um, and I'll talk about that a little bit more in the community meeting here when we have a bit more time than we do in this meeting. Um, because there's a bunch of things that have landed that make it easy to, uh, check things before and after, uh, to inject various things. Um, that kind of stuff. Okay. I could not find it at the moment. Okay. We'll check and send you a link. So Gail already did the changes that you requested. That's why you didn't recognize the code. You're looking at it. No, no, no. Uh, we discussed about the passing some values using the context to the client and passing into a quest. Well, he chose, uh, another way to implement this. We, he made, uh, he makes assertions right after the request without using complex. I guess. Yeah. I mean, it kind of depends on which piece of thing you're testing. I mean, if you inject a background context, uh, then you can extract, think whatever's been added to it from it. Um, but again, I'll talk a little bit more about some of the stuff that, that I did for testing for mechanisms. Um, because what Sergei did here is great. Um, but what I discovered as I was writing more and more tests is that it was more repetitive work than it needed to be. Um, so you could still keep things very semantically clear and simple. Um, in other ways. Um, not in other ways, but basically by, by meeting some of the stuff that's being done here. Um, simple and repeatable. Um, but yeah, this, this is this general have something before, have something after, uh, check what goes in, check the values kind of of testing. Gives you some notion of whether the individual piece is doing its thing. Um, I was not agreed with this kind of solution. Like we have a special server with a test function. And we do assertions inside of this test function. So better to do a request and do some checks after request is complete and use a context as some holder to pass some values from the internals. Um, it will depend somewhat. Um, so for example, if I pass a context in the nature of context is that they wrap each other. So if I pass a context into a request, then the subsequent context that that request passes to the next chain element is not the same context I passed in. And in fact, the context I passed in is going to be not having the additional values added to the context passed in the next element. But if I pass a context into a request, then I would have to do things like the VP, the agent context where its contents are a pointer. Um, you know, that's what we should always use with value with a parent context. I'm sorry, what? Uh, as a check it. We use, uh, uh, the context with value with a parent context. So we should, uh, add a parent one. You do, you do. But if I pass the parent, if I pass context one into my call and my call is a chain element and it goes and, you know, then add something, you know, create as a value, that value is added to context two, which has a parent of context one. So I can get the value from context two, but I cannot get the value from context one. Yeah, yeah, but you could take some pointers to some internal structure for a test. For certain things. And we do that for VP agent. We definitely do. Um, you know, and, you know, you went into some other, you know, various things, but I think the point you're making is that for some use cases, this is over complicating. Um, you know, there are use cases where you can simply, you know, pass in values and then check that values come out on the other end. Um, and that's entirely possible that that's true. Um, so, and I'd like to try and keep things as simple as we can. So I appreciate you calling it out in the places where I've actually made things harder because you get into a group with a pattern and you over complicate the pattern. So. Yeah, okay. Cool. Also created few to those, like move an SM unit and SM monitor. I think this is good. I think we should probably have conversations and perhaps the other way around. Um, I think this is a better place for the Swiss conversations about the naming of repose. Um, because the, the, I had one set of patterns in mind and then it's perfectly valid that people have other ideas. And as we sort of have seen repeatedly, often the ideas that come from the synthesis of many thoughts ended up being better. Uh, you have, you do not want to know what the NSM logo would have looked like if I was the one who the only one involved with that conversation, it would have been hideous. Um, So yeah, we definitely want to talk about that, but I've already started a little bit of that, um, with the command, Ford or VPP agent. Um, you go. Um, and I think probably what we want to do is just figure out what is the same pattern. Yeah. Yeah. Yeah. No, because once you've got it, once you've established the same pattern, then it becomes super easy to get the naming right. Um, and patterns also help human brains process things and put them in context. Um, Yeah. So that's also good. Um, Trying to think what else. Oh yeah. So, so basically I've queued up a bunch of stuff in the agenda to talk about some of the testing in more detail. Um, And, and I, I. Okay. So we got that. And then. Yeah. So, um, On those to do's. Yeah. Defined to implement example test OPA use cases. Okay. So is there anything else that folks feel like we need to talk about in this call? Oh, we, we skipped over a few things actually, because we skipped from monitor to the to do's. Um, you, you talked about monitors and metrics. Um, Yeah. So, um, We don't have him run us love. We don't have run us love. Okay. So we, we, we. We don't have him run us love to talk about the Colonel Ford. Uh, Zemek. Is there anything you'd like to say about the SRIOV stuff? Uh, No updates. Only questions. Hi. Uh, Yeah, I presume. Uh, I mean, some time ago, I asked about, um, Um, when it comes to forwarders and requesting, uh, connections. Uh, so I'm not sure. Oh, yes. Yes. I recall that ask that that's what's actually coming together right now in the order of the agent. So it's, it's, if you want to go take a look at that, um, we haven't yet landed things like the, the testing that's local to that repo, but it'll give you some idea of sort of the simplicity of some of that stuff. And there's some stuff on the agenda to point to that as well. Um, But that at least gives you something to start looking at to get some idea. Does that make sense? Yeah. I'm assuming that some part of the, um, Current SRIOV proof of concept here. Uh, would go to the, yes, to be created comment for, for other Colonel repository or something like that. So, uh, I'm dedicated. Uh, Colonel for other repository for the, I think it's probably true that some of it does belong in the Colonel, uh, sorry, the, the Colonel, Ford or repo SDK, uh, the SDK Colonel repo. Um, and then some of it will land in the, the, the command Colonel, Ford or a Ford or Colonel, um, or command, probably it's command Ford or SRIOV that it would land in, but do, do go take a look at what's landing and the starting to land in the PRs and the command Ford or, um, the agent. Because what's there is very, very minimal. It's basically just a main that call that creates a server. Um, yeah, if you want to go to the pull requests, because I'm trying to find out where the CI is not running right now, which is why the pull requests hasn't been merged. But if you go look at the initial commit of the code and then just scroll down to the main.go file. There we go. Yeah. I mean, effectively all it's got is set up a signal, things on me to catch the signal, set up something for when we need to stop. Um, extract some various things with Viper as parameters. And then queue up the arguments to something that just creates a new cross connect and that's server. And then run the stupid server. And wait for signals. So that's literally a hundred percent of the go code in, um, the command repo right now. And I expect it's probably going to be roughly that going forward. Does that make sense? Yeah, I guess I can start working on something like that's for us. Yeah. I mean, it's very least start taking a look and see if it makes sense for you for us. Because the patterns are good and, but sometimes patterns, despite our best intentions don't always fit every circumstance. Right. So I have this thing I call the no one natural, uh, acts law, a rule, which is it's great. If you want to go take a look and try and follow the patterns. If you find yourself working too hard to follow the patterns, maybe they're not the right patterns for you. So, um, cool. Now we're right up against the top of the hour. I think we should probably go jump on the community meeting. Is there anything else urgent before we do? Um, I think just the Azure issue, we still have problems with it. It is disabled in a Mono rep or some moments. We have issue in the Azure community. I just dropped some email with some folks I know on the inside of Azure, uh, putting them at that issue. Um, and see, hopefully that'll do it a little bit more attention. Yeah. Okay. Thank you.