 Good morning, Nikolai. How are you? Hello, how are you doing? Good morning. So we'll get going here in a couple of minutes, give folks a chance to turn up. Hi, everyone. Good morning. So give a couple more minutes for folks to turn up. All right then, let's go ahead and get going. Let me go ahead and share out the PR issue tracking board. There we go, that is the window I'm looking for. Excellent. Can everyone see the share? Go ahead, I'll speak at once. Oh, yep, I see the board. Fantastic. Awesome. All right, so sort of working a little bit backwards through the in-progress stuff. So we've got the Simplifying Network Service Registry, NNSM Server Registry API. This is actually related to the, let me go ahead and bring this up. I know that you've posted a spec related to this already. And this is sort of just looking at, we just keep stubbing our toe on the registry API as we're doing the refactor, where it just has a lot of things that are problematic. And so we're sort of looking at, is there a way to simplify it that makes sense and that would actually potentially accelerate where we're going instead of slowing it down? So I would strongly encourage folks to go take a look. There's been some active conversation there, but the more voice is involved, the better. And I'll be pointing to this during the community meeting to hopefully get more people involved in the discussion as well. Okay, cool. Cool. Default policy examples. I know that we've got some progress that's been made on this. I think there's actually probably a PR that's vastly overdue for review. Now that I think about it. Oh yes, we have a few PRs related to OPA policies. And I have one question. Looks like I'll continue work on this. And I have a question related to how we can get rollers and operations from the request. I'm sorry, what? Oh, as you know, you suggest to use fields like rollers and operations for OPA policies. Oh, I might have suggested that. It sounds like the sort of thing I might have suggested, but I don't remember why. So, but basically, effectively, the thing that's clear in my mind at this particular moment, please note this does not mean that I did not suggest. Exactly what you suggested at some point in the past was that we were looking at basically on the input side at the TLS info and the actual connection object. Because from those, you can sort of try and make some decisions policy-wise, because you know what someone is asking for or you know what someone has returned to you if you're the client, and you know some things about, you know, who's the immediate requester or the immediate returner of those things. But I can't remember right now clearly why the role would be there. I mean, I can sort of imagine possibly some reasons why, but I can't think of any good reasons why right now. So, okay. And I think you can take a look at one PR related to this. Let me check the number. Okay. Oh, it is PR 225, prepare input for OPA. So 225. Yes. Here is just a simple tools for OPA. You just have a simple function that just converts an assignment put to map that can be read it by open policy agent. And it looks super clear and easy, but I'm interested in what you think about this PR. No, I basically, I feel very embarrassed about this PR personally because I should have merged it a while ago. Basically, I asked a security curiosity-based question and I got distracted and I shouldn't have looked like it distracted. So, okay. Thank you for bringing that back around to my attention, because I looked at it and it looks like a really good move forward to me. And then I got sort of hung up on the why is this roles parameter here? So, all right. Cool. Anything else in the default policy example stuff? Oh, at this moment, that's all. I'll let you know about any questions. Cool, cool. And then we had the bug that came in about connecting multiple entities to the same. And it looks like you fixed this actually. Oh, yes. I have provided PR and it has been merged and also issue reporter also said in the PR, you can, he said that it fixed it. Yeah, no, no. I mean, that's actually, that was my recollection of the situation was that he basically had said this was fixed. Yep, and he said that in the PR. So many things are getting that fixed. Let me go ahead and close the issue out. Awesome. And then we also had this bug on the inter-domain network service, NSM, bulk register, NSC having an issue. Oh, I had a look at this issue two weeks ago and I cannot reproduce this, but I think it is related to specific cluster that user use. And I will try to reproduce this later. Yeah, and we've got, yeah, it looks like, yeah, okay, so you basically asked him for information a couple of weeks ago and he hasn't gotten back to you. So that's totally fair. I mean, you can't reproduce it and all you can do is ask the user for more input and having gotten back to you. And so we're kind of at a point where I don't see how much more you can do there. Then we've got the advanced OPA policy piece. I'm gonna keep this one open because I do wanna respond to Gupta Alec's comment. But, all right. The industrial grade VL3, it remains stuff. I know that you've continued to evolve forward a spec on this. Oh, yep. I have provided status update. And that's a project memory registry elements. This unblocks some stuff like proxy registry and floating registry. And also it helps to Andre to taste in consumer manager. And also I have provided directions of how we can implement IPAM for VL3. Yes, you can open the link. Yeah, I saw that that you'd added some stuff about doing IPAM for the VL3 towards the end. But I think several people have commented on that so far. It is not a solutions, but just direction, how we can do it. And so. Yeah, so I mean, basically, I totally agree with you. This is something that has to sort of be talked through because there's a bunch of interesting ideas here. Both in terms of what you've expressed here and some of the other conversations around IPAM for VL3. And so I think just starting to get some of them flushed out on paper is a really good exercise. And I've added this to the agenda for the community meeting to try and encourage more discussion on this as well. So that's goodness. So I would encourage folks to continue discussing this. And then we've got this bug around leaking GoRoutines. I've wrote cheeks. Excellent. Okay. Yeah, let me, all right. This looks like it's a little bit more than should probably be done live on the call. I'll leave that open to remind me to go and take a look at that. So thank you for getting on that. The WireGuard VVP plugin, how is that going? Yes, I continue work at it. This week, I made a simple handshake procedure. Server sent me a reply if I started initiation. But now I started manually and need to rework at automatically send handshake. And now I can send the Gibo live packets. It is a full encrypted packet. And the server is fine decrypted. I sent some random bytes to test it. It works correctly. And now I work at send pink encrypted and decrypt on server side. This is fantastic. I know you were very, very stuck last week. And my sense was you were kind of, every developer gets into a very, very stuck place from time to time. And then they sort of beat their head against it and they figure it out. And that's kind of where it felt like you were last week. So I'm delighted that you've had all these breakthroughs this week. This is really good. What was the issue with the server not replying last week? What did that turn out to be? I'm sorry again. Last week, the server, you couldn't get the server to reply to your handshake. Yes. What was the root cause of that? I'm curious. It was problem. I compute the checksum as my checksum was wrong and the interface is drop my packet. And yeah. Yes. It's very stupid mistake, but yeah, I only make stupid mistakes. I don't make any smart mistakes. Awesome. Cool. No, I'm glad you figured that out. Hey, Andre. Sorry for being late. I was out of electricity because clearly in the past region that you're currently at. We were just talking about Artem's breakthroughs on the wire guard plugin. Basically he figured out his root problem, which was just a checksum issue and he's made a lot of progress, which is very good. Yeah. Awesome. All right, so this brings us down to the network service manager stuff, which you derived just in time for. Yep. Okay. So I started to merge and create small merge requests based on my internal works. At the moment, do some changes into registry. Found few issues in the current SDK implementation. Yesterday added the URL for the endpoint. It is actually required because peer from context for the unique sockets always return empty value and it's not possible to identify the endpoint callback address. And in case of using callbacks, we need to pass this value with proper callback schema. Yep. That's the thing that frankly is gonna need to be done one way or the other. So better early than late. Yeah. So. So preparing tests for all of this stuff. Mm-hmm. Cool. Awesome. And switch it to my current internal NS manager to the schema you have in the VPP agent forwarder. So change it the same way, most of the code base. Yeah, the way I sort of set that up has some pluses and minuses to it. It's super fast if you're just doing a rebuild because the imports generation caches your binary objects for you as well. As you observed, if you're using the local directory to also work on something else, yeah, I don't have any good way to make that fast. But I think you're in a good position in the sense that because you're not dependent on anything that's Linux specific, as long as you've installed Spiffy Inspire, you should probably be able to run your tests and everything locally anyway, without having to run them in the Docker container per se. Yeah, I have just one obstacle for this. It's using the suites. It's not working for the GoLand IDE from JetBrains. Not check it with Visual Studio Code actually. So it's not so useful. Well, I mean, I- You try to debug some of the particular tests. Yeah, I mean, basically, if you wanna go and just right click on a particular test and say, debug this test, yeah, it can be a little bit annoying. But that's, yeah, so I mean, if you come across a better way that's friendlier to IDEs, I'm definitely open to it. But the- Alternative is to use a cross compilation, I think, and not use suites. Or cross compilation? I mean, in general, different approach. In Monorepa right now, we use a cross compilation approach instead of doing all stuff inside the Docker. It's also pretty fast, but requires some additional- Yeah, but go- Or tooling or something else. But I don't think you would need necessarily cross compile for the stuff you're doing. Basically, for the stuff that's actually working with, that works on non-linux things, like on a Mac, you wouldn't need to cross compile anyway in order to run your tests and debug them with the IDE. You could just run your tests and debug them with the IDE. From the, in terms of the suite stuff, I mean, basically the big thing I was grabbing with the suites was a convenient way to have a single setup for the whole suite and then run a bunch of tests under it. And so basically, if we can figure out a better way of approaching that, I'm definitely in favor. But it's basically the things that I care about in the suites are that they have a suite set up and a suite teardown that gets run. And that's- Yeah, it's nice actually, but tools just don't support it properly. No, it's a question for tools, I think. No, it's the meshing of the IDE with the suites. Like if you just looked at the suites, it's awesome. If you just looked at the IDE, it's awesome. When you put them together, I understand the frustration you're expressing. Cause I've had it too, right? I've run into exactly that myself. So I mean, if you come across something that works better with the tools, do let me know. Cause, and again, keep in mind the thing that I really care about is that there's something that gets run to set up before you run all your tests and there's something that's run that gets run to teardown when you're done with all your tests. Those are the two things that really actually, that I think we're getting from suites that matter to me right now. So if there are better ways to approach that, then I'm definitely interested. So, cool, awesome. Let's see, where were we? I need to remove this metrics thing here. Close the metrics issue in a bit. I keep forgetting to do that. Kernel forwarded a new cross-confile. Do we have any of those folks here? I don't think we do today. Okay. Let's see, I think the rest of it. I've seen me making some progress on starting up getting basic scaffolding in the forwarder SRIOV repo, which is good. Yeah. Guys also preparing a document with use cases. Cool. And so on. One question from our site, it's to find a good device with SRIOV testing. Yeah, so basically what I'll probably do there is poke you towards Taylor and the CNF testbed folks, because they actually have things in packet that they're using with SRIOV. Michael Petterson's a good helper on this. He's fantastic, he's from Intel. Because there are actually, what we can probably do from a development point of view is just use a couple of packet boxes. Because packet does have Nix that support SRIOV. Yeah, okay. Looks good. That's definitely a good direction. So we need to get you hooked up with those guys. All right, cool. So then let's see, things in the to-do pile. I think I'm working on the command forwarder or VPP agent. Implemented open test cases, authorization for the monitor chain elements. Let's see. We did have this bug with an installation failure comment from Sergei. I don't know if anyone has gotten on this. Oh, this is the Helm v3 support. Does anyone take it a look at being able to get the Helm v3 support merged? Yeah, I think we could check tomorrow. Okay. The pull requests, the base will work and find, just merge it. Is there someone that can assign this to? You can assign it to me. Okay. I will assign it tomorrow. Yeah, got it. All right, cool. And then I think, let's see, I think that's probably the stuff that needs to be sort of urgently dealt with today. We should probably start going regroup so we can start the community call roughly on time. Is there anything else that folks want to discuss before we break for today? Guys, I'm okay. So I have a lot of work. Yeah, I do too. Now that I've got the basic pattern going, I've got a whole bunch of bugs to chase down in the forwarder. So now the real work begins. But I think that'll actually work out pretty much okay. All right, cool. I will talk to you guys in about five minutes then. Yeah, so I'm good. See you. See you.