 Hi. Hey, welcome folks, we'll get started here in a little bit as more folks turn up. Hey guys. Hey. Hey, so we'll get going here in just a second. Well, a couple minutes with a few minutes for folks to turn off. We have just actually now hit the starting time of the meeting. I, my psychology is screwed up with the fact that I now have to show up a few minutes early to start the meeting so that everyone else can join. So it always feels like the meeting has been going for a while when it's actually just started. Oh, there's Frederick. Hello. Hello. Cool. So let's go ahead and dive in. Let me go ahead and share the issues board. We can start there and see where we wind up. All right. So, so I know I owe you a review on some of the further work you've done on the server industry simplification stuff. Denise, because I know you've made some updates. Oh, yep, I have responded all comments. Cool. I still wait for feedback. Excellent. I do apologize. I ended up being pulled in a bunch of different directions I didn't expect in the last couple days. Okay, so the default policy examples. I know we've been merging a bunch of stuff related to that that's actually turned out really well. In terms of like how it's sort of shaping up. I think there's one more that I'm aware of that's outstanding that sort of requiring a rebase around some go blanks the I stuff. Also, I will prepare two seconds policies because of I have provided only two policies of your examples. Yep. Okay, cool, cool. Excellent. So that's moving forward nicely. Then we've got this bug that you've been looking at on inter domain and I see stuff. Oh, we have provided a simple pull request for expand expanding walks. And I have asked the reporter to reproduce the problem with a new logging. Yep. Nope, I see that and we haven't heard back from them. So that's just what it is. On the VL three I know you've been extending that out with DNS I got I took a quick glance over what you're doing with the DNS stuff. And it's, it's interesting because you have this bias which I really like towards trying to keep everything as distributed as possible. There is a DNS protocol for allowing multiple servers serving the same domain to update each other with information. It may not be fully applicable to this problem space, but it's probably worth at least digging into to take a look at. It was, I don't remember the name of it and I'll try and dig it up and send it to you. It may be more oriented because DNS often thinks hierarchically towards how do you have multiple, you know, DNS minions that are getting information from a single DNS master. But it may also allow us to actually essentially do zone exchange information using a native protocol for DNS between the VL three NSCs. So we're definitely worth looking at because if it does do what we need, it would be a very clean solution. This is the sometimes unit tests. This is the go routine leak. I presume that we're still just monitoring this at this time. I wrote fix for it but it seems like it's not covers all cases and the bug still produces. Okay, so let's continue to see if we can figure out what's going on there. Intermittent bugs are the worst kind. I'm second generation software. I'm a coder like my father before me and one of the things my father taught me as a child was the worst thing code can ever do is run. So things that things that fail and failing, you know, fail fast, fail obviously tend to be much easier to deal with. How is the wire guard GPP plugin going. Last week, I'm around pink using wire gap again. Now it's possible to connect to VPP instances using that. It seems work correctly. I can pink each other. And now I'm working at timers for key freshing for real hand shaking automatically. Okay, excellent. So to make sure I understand you're to the point where you can see sort of basic handshake happening with the standard wire guard implementation. And you can see reasonable connectivity between two VPPs, but there are some timer things that you have to get right before we can see reasonable connectivity with a standard wire guard implementation. Is that correct. I see. I'm looking at I could to plug in for IPsec. It's plugged in for case exchanging. And I try to do it similarly. Okay. Cool. So it sounds like you're making good progress. So that's excellent. So I've seen some pieces of things coming up. Yeah, I'm trying to put small steps and I know again, giving too much of changes at once. So I have the same problem, right? I usually with the time I you see me pushing a patch, I have made at least three really terrible messes of things and had to go and break them up into more logical chunks. So I'm sympathetic. But it does make it enormously easier both to review and to sort of reason about what's happened in the past and to avoid various issues. So did you see the piece about the revert from of 265. Yeah, yeah, we discussed it already. Okay, cool. You know, so basically, I think, I think that that the actual token stuff is being covered more or less correctly in update path. And without the security package, so that's that's definitely there. One of the thing I will mention is it because it's probably something I'm going to be able to enter the next day or two is that the I it turns out that the spiffy V2 API makes it enormously easier to do something clean and simple than the spiffy V1 API. So I'm going to probably be in all landing something. And I'll point you to it when it lands that uses that instead of using it instead of using the spiffy V1 API. So essentially instead of using a TLS peer, it ends up using what's called a X 509 source. And it just ends up being a much cleaner API overall. And so I'll get that that'll get pushed up. And it'll simply it'll it'll be sort of another round of the world getting much simpler, which is always welcome. Yeah, sounds good. Cool. So I think you said you think you've got the metric stuff sorted out. We're keeping this open just because you sort it out as far as it can go and we'll take a closer look when we're a little further along and see where we stand. Actually, I'm inclined to just close this if you're comfortable with that. Yeah, yeah. Cool. So I don't think we have any of the folks who are working on the kernel piece on this call right now. Unless I'm mistaken, if you are working on the kernel for order, please speak up. I've seen some pieces pushing some initial srio v folder code. Yeah, yeah, yeah. Yeah, we're working into directions for areas working on forward your initial parts and series working on a pocket site to check all the stuff we need. So the guys will start pushing some chain elements. Very soon to work with real srio v and so on. So I discussed internally, we will start with implementing implementing some testing epam like endpoint, which will provide virtual functions address. And before into the main we'll be ready for new SDK, we will be able to check where srio example with just this way. So I guess seven points, we will have real srio v forwarder and it will connect. Fantastic. I've also seen Sergey interacting with the scene of testbed folks and asking good questions about getting srio v stuff up in packet. So, is that, is that continuing to go well from your perspective Sergey. Thank you for introducing Michael and Taylor to me. They're great guys. It's very helpful, helpful. Yeah, they're, they're, they're literally, they're two of the nicest guys in tech, frankly. And so they're, they're, they're wonderfully helpful. And they're also sort of spread across time zones. I know Michael's in Europe, and Taylor's in the US but works a lot internationally. And so hopefully that that's a little helpful. I'm sort of sensitive to the fact that you guys are sort of often skewed off with your native time zone. And I appreciate that very much but anything that makes it easier is probably good. And you do have access to packet now. Yeah, yeah. Perfect. Excellent. Standard. The standard comment I'll make on that is the packet servers are being donated by packet to CNCF and CNCF is gracious enough to make them available to us. And so by all means keep servers up as long as you're doing useful things with them like you beat on a server and you know you keep it up for a week because you're actively working on it. So that week, that's awesome. But do make sure when you sort of get to a point where you're done with a server that you you delete it because we don't want to have servers hanging out forever. It's unkind to people who are being very generous with us. So, okay. We got some of the bits and then okay so those are the week on through those the command for their piece on I've had some things land already. I'm continuing to sort of push some of that forward. At one for forward there, I think it's missing kids registration to this manager. Oh, that's absolutely still missing. It's absolutely still missing. No, you're 100% correct I'm part of the reason that I haven't quite done that yet is just just to be completely honest is that in order to bring it up to the point where I can test it end to end. I actually don't quite need to register it. Yeah, if that makes sense. Yeah. So, and the sort of like get something working get the next thing working it's sort of the last thing I need to get working. Still important, but last piece. Other quick question is now that you guys have had a little bit more time to look at the patterns there. What what do we what do we think we might improve there in terms of the patterns. But it's still in my local wrapper. It sounds good actually to move from a Corba to this new configuration with struct way. It's much easier, I think. Yeah, I, and in general makes more, more easy and more small and clean application. I was super happy. The other thing that I realized that took me a long time to realize about the MV config is, because they're able to use all these various interfaces like you know, text on Marshall and binary and Marshall and whatnot. Most things we care about. We don't have to write on marshallers for. They're just there. So, and it was super funny because just before I pushed up that pattern. I literally had an entire raft of on marshallers that I realized I had put a lot of effort into that I didn't need and that made me happy. Because I could get rid of them. The leading code is good for the soul. Okay, that's good. And I know you had made a comment which is absolutely true that if you do end up using the local directory that a lot of the sort of build speed enhancements go straight to hell. This is, this is also true if you happen to use the debug mechanism for debugging the application debugging the testing. So if you happen to have any smart ideas that are sort of simple and elegant about improving that situation I'd be very interested. Yeah, at the moment, I've just installed this fire and spiffy locally to my Mac just start them and use the environment variable locally. Without using Docker and just do the bug for me D. Well, it works well. Quite frankly, for the stuff you're doing with the network service manager which basically is completely agnostic as to operating system. If you have the testing for the binary actually start them and tear them down. Then you can probably just run go test and everything will be fine. Actually, we could try to adapt the approach, which I've used it for monorepo sometime ago. It's, it was for the background. Actually, when I've mounted the entire tree to a background volume into the Docker into the Kubernetes port itself and started and restarted and compiled site. Real board inside the Kubernetes. So it was most fast. Okay, no, I mean that that that's that's actually that's an interesting approach that the real tricky part with that is with anything is how to make it very simple and elegant and close to existing patterns. You know, you sort of see, see the evolution in public of like the hideous things that I did the first turn of the crank. And I think I'd like to believe they've gotten better, but they were really ugly the first turn. Okay. So, the OPA stuff is moving forward. So the authorization chip monitor chain elements, I'm actually super happy how those are turning out, frankly, the authorization monitor chain elements. One of the things I really like about the way they're sort of turning out is, they aren't actually welded to OPA. Because we will we definitely want to use OPA, you really don't want to sort of. You can view some technology, even if technology is good as OPA or technology is good as spiffy. You don't want to have that running throughout your code if you can help it. Because, you know, world the world is strange and sometimes you're wrong, which actually brings me to a question I know I had asked Denise this earlier in some of the OPA stuff. The input in addition to passing TLS info and passing the connection were parsing out separately the spiffy ID. And I was curious why. Oh, it was implemented by Dmitry. I did not look yet why he's implemented it. I mean, the reason I was asking and we should probably just ask Dmitry if he's if he's around is that I can't currently think of a reason why we would do that and it does sort of produce a welding in the system. But that doesn't mean there isn't a reason. Lots of times people think of really smart things that haven't occurred to me and that I can't see the reasoning for you yet. Yeah, at least for when as manager I've using spiffy ID as identity for a client or endpoint, because we've single entry point like one GPC server it's impossible to distinguish different clients, one from another. So just one way it's to use some identity from a certificate. So I actually had been thinking a similar sort of idea, quite frankly. And so like let's take a look at how we're doing that because I think that's probably the right thing to do we just want to make sure we do it in a way that has a light touch, in terms of how it binds us to spiffy, if that makes sense. I'm not bind to spiffy itself I just take the URL from a certificate. So it's not directly bind to spiffy. So, okay, could have different mechanisms which will extract the identity from a certificate. One is to use a URL bound to a certificate. Okay. Yeah, I know I mean there's, there's a lot of good ways to do it and quite frankly. That's one of the ideas that I actually kind of liked because then you've got, then you're using a straightforward name for a thing. So. Okay, so that's, that's, that's definitely good. All right, and then the go mod control playing the three stuff. Okay, I actually need to go back and respond to that particular fellow. The installation failure issue that we had here. Have we gotten help v3 in or is there some particular reason why not. I think I forgot about it, we check it. Just, I think, merge button need to be click it. Okay, yeah, I mean something else. Okay, so I mean, if, if, if, you know, like I said, if there's actually a problem where we can't get home v3 working, that's fine. But if we can, we've actually had quite a few people who seem to want to use this with home v3. So it would probably be good to get that going. Yeah, you can just click the merge button and Okay, cool. Okay, so yeah. So I mean, if it's actually I'm more than happy to merge it if you guys are saying it's actually in good shape. I'm always, I'm always a little bit leery with patches that are that are dissolved just because You know the presumptions are some reasons. Okay, that's merged. Yeah, if something go wrong, we will repair additional fix for monorepo. Awesome. So that's gone in. And so hopefully we'll get that close to here shortly. So I guess that folks need before we sort of break is in about, you know, a few minutes we should probably start heading over to start the other meeting. Yep, I have one question. Can you please open advanced OPA policies issue. Sure. You can scroll up in progress list. Okay, thank you. Yes. Yes. And here I have one question related to single cluster as what's the example. Am I understand correctly that as what's it is just something like chain of manager clients. No, you're completely correct. So this is one of those things where unfortunately sometimes the networking terminology bleeds in. So what we call composing network services together in a chain is is very similar to a use case and networking that's often called service function chaining. Now we don't usually use that term. When we're talking to the public about this, because while all the networking people go aha service function chaining, everyone else goes, what, because it doesn't mean anything to them that it's confusing. So, but yes, that's exactly it. It's things like the Sarah story with a chain of things. And second question, should we include in the chain registries in the chain registries. I don't follow something like clients did request to manager manager did request to registry. Okay, so you're saying so the client sends a network service request or the client does a look up of a service. Oh, yep. My point here that manager did request to its local registry. So my question is, should we include this registry in the as we say, well, so that the or it's also it's only this is an interesting. So typically speaking that the network service chain that you're dealing with when you're dealing with a composition of this sort. So this is what you're asking is actually a very subtly intelligent question. Because traditionally when you have a chain where you for example had a client and then a VPN, or in a firewall and then a VPN. Then, you know, essentially, what you have in the middle there that we never talk about our things like the network service managers, right, which are part of the path, but we don't sort of logically talk about as being part of the chain usually. Let's let's take this offline and chat a little bit over text after the meetings, because I think you're thinking about thinking about things in a very smart way. But I don't, but which makes me reluctant to give you too fast an answer, because the way I think about the world know you would not actually have the registry as part of the SFC chain. That may actually be a misleading answer because you're probably not thinking about it quite the way I do, but it sounds as if you're thinking about it in a very smart way. So I want to understand you're thinking better. Cool. So we are we are now about five minutes up from the meeting at the top of the hour. Yeah, anything else before we break for that. Just a minute of funny. You can open a link in the chat. It's very funny message why builders fail it after we merge to help. Let me say, hang on. Oh, so to say that he checkers failing. Could somebody please get on that. Yeah, it's just because we're all different. So guys, we don't want it from very sorry for our bills failed. Oh, so yeah, just just getting the shell check going. Okay, so. All right. Cool. All right, anything else before we bounce. All right, talk to you later. Well, talk to you in two minutes basically. See you.