 Hey, guys. Hi, Nikolai. Hi, Rodislav. Hello, everyone. Hi, Jay. Hello, everyone. I'm putting here the link to the meeting notes. I have kept some of the names here. I don't know if we are expecting anyone else. Someone is not here. I will share my screen. Okay. Do you see the meeting notes here? Yeah. Yeah. Okay. Okay, good. So Nikolai Rodislav, Jay, Andre, Alexander. Do we have someone here from the list that is not here? Alexander. Ivan is not here. Ivan is not here. Denis is here. I think that we are mostly... Okay, good. I'll leave her. And Kliplis, fix a date. Yeah. That would be 21st. Yeah. Yeah. Okay, great. So I have two quick topics for today. One is the repost split. One is the NSM con, which is just a reminder since this con is recorded. I just have to say this. So effectively the upcoming events, NSM con, which is the day zero event before it could come in Amsterdam. We have on our side the meeting, the call for papers open. Also, sponsorship is open. We have various types of, various levels of sponsorship. We will have bigger room than whatever we had in San Diego like two months ago. So I hope that it will be a good event for us to organize. Then after that, we have the KubeCon itself for which we have submitted also a number of tools. I hope that we'll get at least a couple of them accepted. We also have our maintainers track being assisted in safe sandbox project. We are entitled to have this time only one talk, but still we are going to do this. So this is KubeCon. And then after that, I guess we'll talk about this also on the call after like morning call. It's a Pacific time morning call, the regular group call. We're going to talk about this, but also we have open networking summit in North America, which is like 20 days after KubeCon. So it will be an interesting and challenging to cover all of this. So these are the, let's say the most pressing and pending events that are in the months to come. We will try to align this with our 0.3 release for KubeCon and SMCon. So this kind of dictates our agenda. So same code is like since our last call, we have started doing the splitting of the repository, which is according to what I can see is going very well. So today we have three new repose split, which was cloud test SDK and SDK VPP agent. I think SDK kernel yesterday. And I suppose I've not seen any messages from it, but at least I suppose probably it will be for the APIs. Because SDK at the moment depends on the main network service mesh repo for the APIs only and it's not good. So I think he will put the APIs into SDK kernel. But I could be wrong. Yeah, I mean we spoke about this yesterday and I'm sure that you probably speak about it also in the world group call today. Yes, it is something that's probably going to happen too. So the ideas that we are splitting into smaller chunks, the main network service mesh repo, that has its challenges, but also it has a lot of great and good things that are going on. Like everything is much more testable, smaller, too many, et cetera. We're taking advantage of the GitHub workflows, which I'm still not sure how these things are used, but apparently there's something that's running fast. I don't know how this works in terms of is it something that you have to subscribe? Are there any caps on the resources that you can use? Can I run kind for example here as part of this? And things like that. How does this relate to the CircleCI? I'm not sure. For smaller projects, GitHub Actions works a bit faster, I think, compared to kind, but for main network service mesh, I think we will still use the kind for huge integration testing drops. Probably smaller parts. Considering if I can migrate the examples repo to something like this. I'm not sure. Okay, that's not... Yeah, this question for to check, yeah. But I mean, we are going, I believe, in the right direction with this. Also, I'm really glad that cloud test is starting to live its own life. I saw that you have a lot of examples. Not a lot, but... Yeah, I mean, the kind is here, and I guess that it's something that will allow people to start. Yeah, yeah, yeah, yeah. And we probably should start considering talking about cloud tests. Okay, probably something that you can initiate. I don't know on what kind of forums or online formats. Maybe you can record a video and we can publish it on YouTube in our network service mesh channel or something like this. I mean, it's a good tool and it deserves its own, let's say, promotion and be able to talk about it. Okay. Yeah, I want to do some minor work to it during this week, I think. Just to do some cleanups, make the configuration file more clean and so on, and we'll publish a 1.0 release for it and switch NSM to use 1.0. I think that is something like this. Yeah, yeah, yeah. I know that we are using 0.1. Yeah, yeah, yeah. Just because some configs are changing state. So I would say that for the time being, cloud test is the first one of these repos that I used. I'm not sure like the SDK is still kind of lifts in both places. So for the time being, I think that this SDK is... Yeah, it's all to SDK. Yeah, when you SDK does not contain all of this stuff yet. So it actually, when you SDKs a few projects, the SDK itself is for core and the SDK for VPP it's in separate repository. So it will be split into two parts. And it's a bit different SDK. Yeah. So it's similar, approach is similar, but the utility classes is a bit different. So other interesting thing that we have merged, and I think that it kind of created some problems, but this needs to be checked. I merged this Hub 3 kind of support. And... Yeah, we already have a fix. It's in a pull request 2064. It's in progress now. It fixes Helm NSM install.sr script. Fix it. Fix a master. So after it built, it will be finished. It will just merge it. And I hope master will be green again. Okay. I'm not sure where this came from, but... It just vice versa in condition. I just change branches. Oh, yes, yes, yes. Yeah. Okay, interesting. But then how was this passing before? Our guess is after a brace changes. Oh, okay. Probably, but I'm not sure. Okay, fine. Then if that's the case, then great. Okay. And I hope that at some point we are going to completely migrate to Helm 3. I'm not sure what the status there is, but at some point we need to draw. Probably in Yevdor, like, I don't know, like half in the middle of the year. Good. Okay. What else we want to say about these things? Yeah. I think one question you wanted to discuss with Artem and with Radoslav. Artem is working on a wire guard support at the moment. I want to do some changes to the kernel forwarder. So questions mostly for Unical and Radoslav. Do you have any upcoming work in the kernel forwarder or we can just safely do some refactoring into it? Oh, I think you're safe to do it for time being. Okay. Okay. Okay. So Artem will do some refactoring to support more remote mechanisms into it or easily. So we will include you for a review after he will complete his work. Okay. Okay. That's really great and interesting. I mean, I have seen a couple of talks about what was the project, Submariner or something. Artem? I'm not sure. As I know, it's two Go implementations for a wire guard. Well, wire guard have their own Go repository. So we can easily use it with their API. I'm not sure about Submariner. Yeah. I was, I was trying to figure out if Submariner was using wire guard. Wire guard has very easy configuration, almost like VXLan, but instead of Vinii, they are using public keys. So it's, it shouldn't be any, we shouldn't have any problems with it. Yeah. Yeah. I'm not, I'm not talking about this. It's like, are we competing with this specific specific base connectivity out of the books? Yeah. I think it was wire guard that they were using. Yeah. Okay. Yeah. Let us know when, when there is a PR. Yeah. So we, yes, as Rolofa said, we have a couple of small things that we are planning to do, but nothing that cannot be postponed and put on top of your work. So I know that one of the things that were actually, we kind of postponed for too long was that the internal folder still has to, to be refactored to do the SDK API style thing, like request and close and all these things. I'm not sure if, if this is probably one of the things that probably is pending and needs to be done. So if you are going through it, I guess that you start with something along those lines and then put on, put the other things on top. But that's, that's up to you to, of course, to decide. There shouldn't be any conflicts. I just found some places where VXLan is hardcoded. So I will, I will put selecting mechanism there and that's it. So there shouldn't be any conflicts. Okay. Okay. Okay. What is the reason for wire guide? I kind of missed the project, the subject. I think it was something related to the public clouds and the fact that wire guide kind of more easily traverses the, than VXLan for example. It is like secured by VXLan. I see. Okay. Okay. So it's about security, not, not that much about performance. Okay. But do we know anything about performance? I mean, do you think that it's going to mean, of course, we're not going for performance once we are considering remote clouds? That's, that's for sure. It's just, I found some information that it is much faster than another secured connections. It is almost like VXLan, it's working on getting level with Ubuntu system. So it should be very fast. Okay. Good. That's, that's a good thing to know. Okay. Okay. So any questions, Jay, do you have any, anything that you want to put on the table and discuss? Yes. Yes. Actually, I just read a news from Twitter. I think the Koffo paper is not open for KubeCon China 2020 now, I believe. Yeah. Frederick just posed that to it. And so my colleagues and I are considering some meeting a talk, but we have no experience before. Since this is first time trying to do that. And I believe that many folks have done this more than once. So really appreciate if there's some advice and suggestions for like topic selection. Like, is there a template for writing such a proposal so that the topic has higher chance of being accepted? So I was on the program committee on the, like a reviewer for the networking track for the KubeCon Europe. This was my first time here. So probably just limited, limited experience. I know that had much more experience in this. Probably they can, they can tell you more, but at least from my point of view, what was, so one of the things that you should ensure is that the topic is kind of original. I mean, it can be a respite of something that someone else is talking already or you have talked about, but it shouldn't give the impression that it's something that you go everywhere and talk about them. It's one and same thing. Like, sure. Yeah. Yeah. Actually, yeah. That's one of the things. And then probably the other thing is try to be as explicit as possible about the, what you want to talk about. I know that sometimes people, when they submit talks, they try to leave the door open so that they can do like last minute changes and whatever. Right. But for, from the reviewer point of view, it's very, it's very hard to, to judge if this talk is worth it. If you read about some vague, you know, statements like we are going to show examples and it's like, okay, tell me what these examples are. I mean, they, in this specific, specific case that we were talking about, we are showing to, to show examples of connecting multiple clouds using choir guards on top of the NSM API. So that's, that's a lot more specific than just saying intercloud connectivity, blah, blah, blah. Then it's for me, it's like, okay, I don't know what this is about. Yeah. If you see what I mean, that's, that's, like, when I read the abstract, I should be able to kind of imagine the agenda of your talk, like, I'm going to talk about this, this, this three, three, three topics, I see them, they're clearly connected. Also, I have seen people that want to talk about too many things in 35 minutes and 35 minutes is not that much. I mean, taking into account that having one question will divert them for at least five minutes, maybe seven or eight even. And then 35 minutes is really limited. So really focused scope, narrowed to very specific topics. It's, it's really good if you talk about real life examples, something that's really coming from the reality, not some, you know, made up things like, yeah, theoretically we can do this and these things. That's, that's interesting, but probably not, not what you've come is looking for. Sure. So, so is it true that the topic must be based on open source project? I don't know the details. I would definitely prefer if it is about open source projects, but for sure, when you submit, you have to relate to one of the CNCF projects. I am assuming that you have to say NSM. So for sure, you should say something like, we're building a solution on top of NSM and we're going to share our experience with using it, participating in the community or whatever you want to say there. But you should talk, like in the abstract, mostly about the open source nature of your proposal and not focus on the, you know, whatever you did in your appropriator. I think of course, during the talk, you can mention and you can refer to whatever you did in internally, but you should mostly focus on how the open source, how the community, how the framework, all these interactions, how did these things help you? Interesting. So is it allowed to submit multiple topics or just one topic for each proposal? I'm not sure what you refer to. Oh, I mean, like, for example, there are probably the committee, for example, if I would like to talk about NSM, probably talk about another open source CNCF project. It's, I think, a question as for how long the talk is. Oh, I mean, so what I mean is probably, maybe it's going to two completely different topics, areas. For example, one topic I would like to talk about network, another topic I would like to talk about security or whatever. So this would be two different proposals. Okay. And at least for Europe, like you were restricted to submit, I think, two, you should read the guidelines. But there are restrictions. I don't think that they are going to accept more than two, if not even one. I know that the Shanghai one is really, really slim, like in terms of space, like a room for having many parallel talks. So I doubt that they will accept more than one per speaker. But you should read the rules. There are... Here, I guess, that they will tell you. Cool. They still remember requirements and then they tell you. So they tell you what you have to do. That will be great. I will try to join this year also. I'm in talks here with my managers. It's interesting because this year they have distributed it like we have KubeCon at the end of March, like in Europe. And then it's like four months later is... Is it four? Yes, four months later is... Yeah, three or four months. Yeah, so that's good because we have time to prepare from one to the other and also there is time for the project to change, to evolve, to do some additional work, not just talk one at the same time, conference after conference. Sure. Thanks so much for the guide and looking forward to meeting you again at KubeCon China. I hope so. That's it. Thanks. Okay, thank you. Okay. With this, do we have anything else that we want to discuss? I guess there are lots of things, but something that we can... Yeah, we have three minutes. Just one. I think the floating into the man is still pending. So I think our term will do rebase on the latest today. And if it pass, I think we need to merge it today. Since we will do more refactoring if it's decay and so on. Yeah, yeah, yeah. I guess such huge pull requests would not be very good. Okay. Let me just quickly check. Have I approved it already? Yes. Okay. I am in favor, like, if you want to merge it, I mean, from my... From my side, it's... It's okay. So, yeah, just rebase it and... Yeah. We'll try to rebase it, check if it pass and we'll merge, I think, today. Or wait for at last time approval during today pull request meeting and merge it during the meeting. We never managed to find something like whatever the Kubernetes have. I know that they are maintaining their own bots, like, to be able to rebase, like, the CI robot and... I know that they have something... Let me try to find some... Something with more commands that probably can be... You can have an example of this. Yeah. You know, they have this, like, retest. So, all these things and then they have rebases and all these kinds of commands that they can do here. It would have been great to... If I could have just said, yeah, rebase and then the PR gets rebased and... You don't have to do that. But I guess it's... Yeah. Kind. Yeah. Okay. Whatever. LGTM. So, this is the merge command. And, you know, it's just... Very advanced. But I guess that there is a team of people that are taking care of these things to be maintained on their own. Okay. Good. With this, I am done. And if there are no other topics to discuss, I suggest that we finish here. Yeah. See you in a few hours. Okay. Thank you, everyone. See you. Bye. Bye-bye. Bye-bye. Thank you.