 Hello. Hey, okay. So I think we've got several folks who have to drop at 25 after so we may want to Start a little earlier than we normally would cool, let's jump straight in then so Since we have limited time One of the questions we should ask is is there anything that the people who have to drop early would like to get to Okay, and I think a lot my insight They might hurt So yeah on my side, I don't have I mean, maybe a Quick report on the morning meeting that we did okay Earlier meeting okay, there is there is a there's a line item for feedback from the ancient community call Yeah, let's start there and then we can then we can double back Yeah, so we At the beginning it was mostly The active committers so Several people from the sort and then we had a good discussion on some of the pending PRs both on the examples then we went quickly through the Tim module PR and This PR specifically maybe maybe it's worth also talking about it A little bit here It's interesting to see what what other folks think. Yeah But yeah, and then we had a Couple of people from From the Asia time zone joining From Jay from Huawei about The need to use IPs on the on the links both on the end point and on the client side And At least to the best of my understanding and this is what I explained from my experience with you know putting together the VPN example Then all you know we have extended with a couple of past through and points essentially that This was a bit of to the best of my understanding we currently more or less mandate Require that there's going to be an IP I don't think so actually I think the IPs are currently optional and this is kind of intentional because if thing I'm passing over is just needed at frame Me it's possible that there's a bug in the code that's causing it to look like that, but it they they should be purely optional Yeah, yes, there are you Yeah, if they turn out not to be optional then we probably want to get an issue open To make sure that that we fix whatever bug is making them mandatory now We do tend to use them in our examples because most interesting examples Involve something that has a source IP at least But it is certainly not the only kind of examples Well, I'm not aware of like the past through Endpoints that not we have They do this trickery with passing back and forth IPs between the context of the Client and the context that that is going to be returned back to As a result of the request to the endpoint So this is how we kind of pass The IP information Through the past through endpoints totally Yeah, no, I mean the thing the trick there though is in that use case you have a situation where The final CNF in the chain is providing a source IP and you'd like that to actually be the source IP For the client and the intermediate pass-throughs don't have any opinion on this at all In fact, they're a good example of not having an IP on the interfaces because they just pass it straight through Yeah, but I mean it's It's definitely an interesting question and the truth is most interesting examples are gonna have them But I can think of some some of which last I checked still had big footprints Where you don't Okay, yeah, we might want to figure out a pure layer to example where Client doesn't doesn't need an IP or he has the IP pre-assigned actually that that could be I Think that's actually probably a really good idea because I can absolutely see how somebody looking at our examples would get the impression that Jason had Yeah, okay. Good. Yeah. Yeah. Mm-hmm. That's that makes some sense. Okay. I will Look at it in the in the examples and I point see if I can I can figure out something that that makes sense good So that was more or less about the call. I think that it's useful. I'm very glad that we keep keep doing it Let's continue In two weeks I think that's probably a very good idea And these things take a little time to grow. I mean when we started doing these calls They weren't instantly gigantic Then maybe a quick quick glimpse and the multi module report. Sure. Just yeah, just So we we went through it today And my only I mean of course if the the result of it is going to be a better Dependency management for the modules that are going to For the projects that are going to depend on the SDK for example, so yeah, certainly restrict the Dependencies that you're tracking with the current With the current portion that we have my only concern is how do we maintain this and also are there any best practices that we can follow from other projects I mean We spoke last time that this is the near-term solution For a bigger problem that I think that we have And it is that we have too many things Just happening in the same in the same tree Yeah, she results, you know in in a lot of of course dependences because everyone It's it's where we are of course So, yeah, of course the the the I I can agree that this is a short-term solution. Okay near-term solution but near-term and My only question is how do we how do we plan to maintain this? For example, if there is a protobooth update, what do I go and Just change this everywhere, you know the you know five ten whatever number of Mops files we have and Of course best practices But I think we should probably look into both. I think those are sort of the student observations The other thing I would say is in addition to being a near-term solution It also essentially allows us to stage ourselves for breaking the repo up Right because the work that you have to do to successfully break the repo up is going to intrinsically involve Introducing separate go module dependencies and the interdependencies among them There's a displaces actually see the shape of the world if we were to break things to the separate repos and from there We can sort of make decisions They're more intelligent by doing it in a stepwise fashion. Yeah. Yeah, of course Cool So was there any other Discussion that happened from the Asia meeting or stuff that you wanted to bring up that came out of that because I I'm super excited about the Multi-module repo and I'm also super excited that we're thinking through like how to properly handle this care and feeding Nothing on my side Are you are you here? Yeah, so I love told me today that he had some troubles when he was re-basin Something was not working so Yeah, I I do have an issue for that see I stability last week was terrible And so there's been a lot of work going on trying to fix that I Also wanted to mention about the Cutset to verify to verify the things that work Not only on see I because I'm mainly using the background setup and most of the I'll say the case related targets in the make files were either broken or I don't know. Yeah. Oh Okay, that's interesting. Um So something that we can fix. Yeah, yeah, look, do we I believe you I think it's on issue open for that Is that correct? Yeah, and there was another one after mine actually that was related to that same issue So I think we we also had a transition over to the home charts that was going on as well Are the home charts not working? No, the home charts are working but Um Yeah, it's basically we have some targets that are living behind that are not yet updated. Okay That actually brings me around to this is something that I that I thought we should probably talk about as a community Which is sort of the cleanup of the make files Yeah, and this is something Denise have done. Do you want to talk a little bit about it Denise? Yep We have We had eliminated config to use Helm's but we did not delete a deprecated API and YAML configs and By this PR, I've deleted this mostly. That's it Yeah, I think you also updated the documentation so that it talks about the the recent YAML stuff as well So I guess we're just love. Does this look like it's starting to fix the problem you identified? Um, yeah, more or less. Yeah, but yeah Okay, cool I mean, I did want to I did want to raise it for discussion here to see what people thought because it is kind of a big change in the make file machinery and It struck me is generally good But the sort of thing that they would be kind of shocking if you didn't expect it So I did want to give folks a chance to talk about it a little bit because effectively it is moving everything over to the home file stuff Okay. Yeah, and one thing that I wanted to bring up is that Sometimes there is a difference between the behavior of the projects if tested by the CI and if tested on hand actually with Vagrant or kind or something else. So Yeah, it's it's worth testing manually as well Okay. No, no, absolutely always always and or improving what we were testing in the CI Yeah, yeah, cool Awesome. So we've been kind of jumping around here. Do you want to take the helmet in Frederick? Sure? Okay, so back to the So back to the start. So we have three recurring. Well, we'll say one recurring meeting at the moment, which is this one Can we remove those two for the moment? Sure case in documents Yep Well, we also have the telecom user group that we attend on a regular basis So there's one at 8 a.m. On the first Monday and one at 4 a.m. On the third Monday all Pacific time We have the CNCF Network working group which occurs every two weeks on Tuesday We have on us coming up next week in Antwerp with for accepted talks in a telecom telecom user group and CNCF test by tutorial so This brings up the question. What do we want to do for next week's meeting? So how many folks who are regular attendees are going to be on us? I imagine quite a few given the fact that we have so many talks accepted Might be better off the other way Yeah, that's actually true. I I mean I will not be at on us, but I don't know Yeah, I mean given the number of people who are missing it might be better just to cancel next week Yeah, I'm happy with that we can cancel next week and Then reconvene Let's see what they would to be calendar says the 1st of October Yeah Would would that work for for others is I don't think we have anything any burning issues between That's coming up between now and next week cool, I vote to To cancel it ultimately it's up to you since you're the one here Ed No, I think that's probably a good idea Okay, I'm updating the document to it correctly reflects this There we go, cool. All right, so we correctly captured the next call stuff great so back to Major events we have the CNCF webinar coming up on October the 2nd, which should be on the Wednesday Do you know if that's gonna be live streamed or is it just gonna be a recording? I think it's live streamed Yeah, so feel free to join us. Yeah bring questions. We like questions We have open source summit in Leon, France with a talk accepted we have Cube con and proud native con in North America coming up with NSM con We have a significant number of talks submitted now and so we're pretty pretty happy with that So we will We will work to get those talks Worked out and published We have the Kubernetes forum which is coming up in Seoul and Sydney So the CFP is already closed for for that But if you are near Seoul or Sydney at the time Feel free to join The CNCF and I believe Dan Kohn will be there so We have the social media community team, so is Lucina on the call Lucina did let me know she's not going to be able to be on the call today But she did go through and update the stats leading into the call Okay, so With that then She posted that we have a four and 26 followers of an additional eight in the last week 1847 falling with 29 and for an a for tweets and retweets with an additional 28 from last week And she's made a variety of interesting posts Basically outlining our OS and NSM Calls And she's also going to post reminders on the ONSEU talks the CNCF webinar live tweet Talks from next week and the co-presenting of the CNCF test page tutorial Is there anything else we would like to ask her to post that it's not on here? And so Okay, let's jump into the main into the main agenda, so good beginner problems fuzzing bugs So we have two fuzzing bugs Can we describe what a fuzzing bug is? Yeah, so basically fuzzing involves taking your code and running Essentially trying to walk the tree of possible inputs into it. It's a technique that people use to detect crashes and security issues And we've recently had some folks show up in the community who have quite kindly volunteered to fuzz our code for us And they've started the process of fuzzing it This will eventually turn into PRs with fuzzing unit tests but for the moment they've been reporting back on problems that they found through the fuzzing and These end up being almost ideal starter problems, right because essentially What you get is a panic That tells you exactly where the hell it's upset Right, so the literally says there is a problem. The problem is here. This is the kind of problem And that makes them sort of ideal places to Start and then we've also got comments that point to unit tests for these cases so you can go and do the reproduction Book moons is the one who's doing the fuzzing there. They're awesome Um And so if you are part of the network service mesh community and you're looking for a way to get started in contributing to network service mesh these are Pretty straightforward problems that probably would take somebody, you know an hour or so to get going and resolve If you've basically got some background in dough, but not necessarily some background in the network service mesh code base and so I've been sort of calling them out and tagging them that way Because I it's always useful to have good starter problems for people to work on Nice, so how would a person find those fuzzing bugs? Is there a tag on the repo or? Well, there's a link here and then there's also There are tags. I've labeled the bugs with fuzzing and with good first issue So you can find it with either one of these tags as well So we have CI So we already spoke about CI stability Yep, seems to be settling down again Part of it turns out to be and this is one of the advantages of running CI as extensive as we have is that if you run extensive CI and you run it a lot You shake out all of your highs and bugs And so as the code evolves and you a new fix comes in and G it passed see on it got in Occasionally it had a highs and bug and so it shakes out and stupid in CI stability a little bit going forward But because there's so much CI being run all the time you do catch them. So overall it makes the code harder It hardens the code and produces more stability But occasionally you have a bad week and we had a bad week last week, but it seems to be resolving Frederick, I think you're on mute. Oh Sorry about that Cool, so just jump into It's a simplifying the make rules So I think we talked about simplifying the make rules when Yeah, yeah Cool, so I don't think there's anything left to say on that then so just jump straight into in progress sure, so I think the SDK refactor of the BPP agent data plane that was stuff that you're working on Denise. You want to say a few words? No, it is completed and I wait to your review That's it. Yeah, folks in general could take a look at it Effectively what's going on here is the the refactor of the SDK particularly providing things like internal traceability and other things And provide, you know, it worked out well And so we started looking at other components of the system that could be refactored this way So for example, we do expect people to be building the just like we have the SDK for network service in points because we expect people to be building network service in points We do expect as we evolve towards multi data plane for people to be building data planes of various sorts Particularly in the support of hardware NICS, but that's not the only set of things people might do it for and so we wanted to make that easier as part of the system so Um SDK style refactor of the network service manager Andre, do you want to say a few words? Yeah PR is mostly in so the general idea could be looked at and review it in it. So we have two separation of establishing the network service in the NS manager two Small pieces with chains of smaller network service operations all of this Implement our network service requests Protocol And we do it for both local to remote and remote to local. So you have two chains of operations At the moment I'm working to simplify the healing stuff we have at the moment to have third chain so all of this Reuse a small pieces of code. It will be easier to test and Easier to maintain Yeah, and part of the idea here also is that there's people we expect people to be writing network service managers for other environments like the M environments and bare metal environments and so this will hopefully make that process easier and then It also We expect to start seeing more proxy network service managers things like we've talked for a while about the create proxy network service manager And the idea in both cases is just have reusable SDK components You can chain together for most of what a network service manager does and then you can just write the one little piece That is different for your particular network service manager. So maybe your network service manager instead of turning to A network, you know an SM data forwarder, which is kind of Kubernetes specific Maybe it turns to some SDN Controller and asked it to do something, you know that kind of thing Cool. So we've already talked about the multi module repo stuff Today's do you want to say a few words about the internet context stuff Yes, sure. Yeah is provided and ready for review But I have one question Provided question into PR and Mostly this issue About that we have a simple problem that if NCR dies and recovers on NSC side we have out of date MAC address and This PR should fix this problem Effectively, it's an arpentry problem. So yes, yes, yeah Any any kind of healing where a client gets automatically reconnected to a new network service endpoint so that it keeps continued service Without Ethernet context, there's going to be a different Ethernet address on The end that it got reconnected to and therefore your arpentries will be mismatched and it's not a fatal error You know ARP is smart enough that it will figure it out, but it does result in some lost pings Which makes testing annoyingly flaky? and it also is just not as Robust of situations we can construct and so Ethernet context allows you to optionally Essentially to optionally carry that Ethernet context with you so that when you go to do the the healing and the re-request You can get the right behavior so cool So I think we've talked before about the security stuff Ilya I think you've been mostly blocked behind the CI flakiness on this. Is that correct? Yeah, right and now I just checked and there are only one test failed example hell with PN which I hope will be fixed by our fix mine and entry so Excellent. I think after that fix will blend it we can merge secret Sounds fantastic and then Artem, I know that you're waiting on a bug fix from VPP you think on the SRV6 support. Is that correct? Yes, okay Cool, so we will continue to chase that down So Radislav do you want to say some stuff about what's going on in the kernel forwarding plane? currently we've lost Radislav and Ivana and Nikolai so they were going to talk about these items, so I think that's kind of it for The status of the project for this week that I'm aware of do other folks have other things they want to raise So I think we're sort of at the end of the agenda for this week. Do we want to go ahead and yield back the time Frederick? Yeah, I think that's a good idea. So Let's see so as a reminder there's no meeting next week looking forward to seeing that several of you Next week as well, and we will see you all again in this meeting On October 1st same same time two weeks from now. Thank you. All right. Thank you