 Hey guys. Hello. Give it another three or four minutes before we get started. Good morning. Happy New Year everybody. Happy New Year. Happy 2020. So just as a reminder if you ever sign any documents this year and you're in the habit of putting the last two digits of the year, make sure to write out the full year because it turns out that if you just write 20 it makes it easy for someone to stick 19 or 18 or something else with their choice behind it. Make it... What? Yeah, because the year starts with 20. So if you just write 20 to abbreviate it then you can write like this thing was due to me in 2019 rather than 2020. Okay. So I guess the real answer is don't sign documents that with untrustworthy people, but if you can't do that then make sure you write out the full date. While we're waiting can we get someone to share the agenda? Hi everyone. Hello. Hello. Cool. Thank you and please add yourself to the to the list if you haven't done so already. Thank you, Lucina. Lucina posted the link in the chat. Okay, let's get started. So welcome to the next Network Service Mesh meeting. We have this particular meeting every Tuesday at 8 a.m. Pacific and we also participate in the CNCF telecom user group, which occurs every first Monday at 8 a.m. Pacific and every third Monday at 3 a.m. Pacific. Good for Asian time. We also are participating in the CNCF networking working group, which is recently been rebooted. It meets every two weeks on Tuesday at 11 a.m. The last meeting was on December 19th. I need to ask Lee Calcote when the next one for this year is going to start so we can get the cadence up on that again. And with that we have a couple major events. So the first question is do we want to keep Fosdom 2020 on the list? Is are we doing anything? Are we doing anything there? I don't think so. Highly encourage you go to the Fosdom still even though we don't have a presence there. I'd say it's a very fun event. We have we have KubeCon coming up and with KubeCon the call for proposals is already closed. The notifications should go out within a couple of weeks. His so we are we have several topics that have been that have been shared into into the proposals and Taylor has a has comprised a list of people who have selected themselves into into the list. And we also need to prepare the maintainers truck. Yeah, this is this is true. And so I don't I don't recall if we I don't think we have a prospectus up for that yet. Ed, do you have any information on that by any chance? I'm sorry I'm on an SM con. No, it's on the list of things that that need to happen this week is I know effectively getting a prospectus together getting a CFP out, etc. So definitely need to get that moving because time is running a little bit short. But the good news is we've done this once before so it should be quite doable. Yeah, and so we we have a larger room now or at least that's what I've been told so that should help with not running out of seats and not running out of food. We assuming that we get a food sponsorship. We have Open Networking and Edge Summit in North America as well, which is going to be in Los Angeles. The call for proposals closes on February 3rd. So make sure you get your proposals in if you intend to be in Los Angeles during these dates. We did this announcement last time, but we'll do it again one more time. We donated the $2,300 we got from the registration fees of the last NSM con to the CNCF Diversity Scholarship. I believe the intention is to do that again in the next NSM con. We will have that enumerated in the prospectus as to what exactly we will do with that. But please if there's any talk that you're interested in or you want to share with others we have the NSM con playlist and a YouTube channel that has the set of talks. So these are specifically for NSM con. The cube con NSM talks are on the CNCF channel, so you'll have to go rummage through the CNCF channel there for those ones. And with that we have the social media community team. Lucinda, you have the floor. Hi, happy new year everybody. Happy new year. Great. So I've had some help with keeping things moving over the past three weeks or so. And in the past three weeks, we've gained 21 new Twitter followers and 19 new LinkedIn followers and have posted about 32 tweets and retweets, including the NSM con EU 2020 announcement, the two calls today. And there's an article Kubernetes continues to shine that featured NSM. And we also posted videos of each individual NSM talks. So that's going to be both on our Twitter and LinkedIn. And just this morning posted a recap of the zero dot two zero release. So the plan, once we have the link for the CFP for NSM con, we'll go ahead and share that. If we are needing sponsors to sign up, we can go ahead and share that and let them know that it's open and share the link on how sponsors can get involved and any retweets that mention us in the press and open the contributor podcast. Is the URL available for that one? I haven't seen a URL yet. We got a an example of it just so that we can review it and make sure that our respective PRs are happy with it. So once we've gone through that cycle, we will have it up and or they will have it up and we will share it aggressively. Sounds perfect. Is there anything else you'd like to see in this next week? I think we may all just be slowly fading in from the break. Well, when I say share it aggressively, I mean, friendly, friendly, sure, friendly. You can be friendly and aggressive at the same time. It works. It's confusing, but it works. Cool. So is there anything else that you have to see in it or is that it? Very good. I think that's it for the moment. Thank you. Thank you very much. Cool. So on the agenda, so we have some things to discuss regarding crowd test. Ed, you have the floor. Yeah. So basically, I know we discussed several times the desire to sort of break things out of the main network service mesh repo because it's not that it's strictly objectively large, but it's definitely thematically large. There are a bunch of things living in that repo from a thematic point of view, even though the number of lines of code is still relatively small. And so one of those things is this tool cloud test, which is basically a completely kickass tool for basically running tests across multiple public clouds and other things. And we use it for all our integration testing. And it's relatively self-contained. And so there was a desire to pull cloud test out into a separate repo. And so we have folks who are interested in actually going and doing that work, but we wanted to make sure that we sort of double-clicked with the community and see how people felt about it before new repos started appearing and things started flying around. I think my preference would be for it to be a new repo, something that we can then pull in. Yeah, with the conversations that we've had on cloud tests, there's no dependency on anything else. So it should be something trivial to pull out. And I have interest to run it in another context outside of NSM as well. So having it in a separate repo would be very helpful. Yeah, I've been one of the proponents of this idea for some time. So I don't think that I need to say. Yeah, I mean, in all honesty, I expected people to be very positive towards this idea, but just having a repo suddenly appear and stuff move around without talking about it seemed like the wrong thing as well. So I wanted to make sure we brought this up as a matter of conversation. We probably want to do a time permitting, sort of have a general conversation about where we might want to go in terms of generally breaking things into separate repos. And in sort of the timing of it, the cloud test seemed like a very obvious choice because it was low impact. We can see how that goes. But there's also a question of how we end up doing CI when we have multiple repos as well that we want to think about. Yeah, I guess just a simple go get to just bring us the, where is the, yeah, the binary and then you just use it. I guess that would be it. I mean, you can even package cloud test in a container, which is probably a good idea. Okay. Yeah, I mean, so like either way, I could absolutely see. So speaking of this, one other thing that actually bugs me is this Gates Conf thing that is supposed to disappear, I believe, over time, but it's still kind of hanging around here. Are we still using it? I think that some bits are used here. For example, the cluster setup, I think it's done through these files here. Yeah, we wouldn't mind that a bit of house cleaning coming together. No, no, no, it's a separate topic. It's not related to cloud test directly, just like something that appears from time to time. Yeah, I mean, it's the new year. We're all sort of in the mode of house cleaning, I think. Yeah, everyone is rested and slightly overfed. Slightly? Yeah, maybe a little more than slightly. Yeah. Yeah. Okay. So anything else? Those are some of the things that came to mind. I mean, we talked last year about the path stuff. I'm sort of busily poking at the refactor work for that. I was hopeful to have it done over the break, but my break ended up being a little bit more like a break, which is probably healthy overall. And so I probably still have about another week on getting some of that code done, but that will be exciting as it comes together. So today in the morning, we had the Asia time zone friendly call. And Andre brought the topics always poke a little bit about, you know, possible solutions of how we want to attack this. I wouldn't call it a problem, but this challenge, let's say it is essentially how do you make A be able to connect to both B and C without really understanding that there's B and C. It just says I want to connect to each and every one of these existing, at least that's my interpretation of the program. I think that it depends on the way you work. It can kind of suggest the solution. So I'm obviously suggesting a solution here, but there's one set of problems, which is the how might I do a full mesh? And then there's a more sophisticated problem, which is I would like to do a partial mesh, but via a complicated set of things that are not going to be expressible in the sort of match policy stuff. So Andre mentioned today that they had some ideas that they wanted to share with the wider. Fantastic. So yeah, I did just pretty simple, actually. At the moment, at the current state of NSM, we have a point to point connections. And the network service and point provide the pair of AP addresses to connect between one point and the NSC itself. So the idea is to think about for NSC to provide not the point to point connection, but the network. So we will have a dedicated network service and point. It will provide the network. It will assign the AP address to the different clients and NS managers will do the required virtual network with any of the different approaches. So I mean, effectively, you have an NSC that provides whatever the network you need as a network services. And so network service mesh is still just doing the V wires, but somebody is writing an NSC that gives you the L3 network that you're interested in. I think that's actually definitely the thing. I think though part of it is you still have whatever network service endpoint that is providing that you may have different up them in different places that need to connect to each other with V wires as well. Yeah, of course, it's just an idea. It's need to be work it right. The lovely thing is that idea can be explored in all kinds of different ways. I mean, one of the nice things about network service mesh is that there is no one true way to solve that problem, which means, you know, if somebody thinks of a smarter way to approach it, they can just write the network service and points in a way they go. So I don't know if Jay is on the call. No, he's not. But he also suggested some solution that they're working on. He will probably try to present it on the next work group call. So they have some ideas, something that they're working on, and maybe, I don't know, this can help eventually. I don't know. Ideas are exciting. Yes. So Andre, do you have any kind of diagram that you want to share? No, no, no, no. Yesterday, we read about this problem, and we discussed internally and discussed on Asia time meeting and what's almost. So it looks interesting. I would suggest also you might want to reach out. I know Ilya is in contact with him. You may want to reach out to Tim because I know he's also thinking in this area. So I'm perfectly delighted to have people explore multiple ideas, but it is better if people who are going to explore the same idea discover they're exploring the same idea and collaborate. My only, as we just spoke in the morning, like, okay, my morning. In the earlier call, let's say, my only concern, okay, it's not a concern, but kind of thing that I would like to make sure that we keep the API as generic as possible and not in the attempt to solve a particular use case to make just kind of, you know, solutions that are meant to solve the particular use case. I'm a million percent with you on that. I'm completely, completely, completely in concurrence. You know, I basically, I have two principles that actually in my, the way I think about code, that actually that support that. The first is you should keep your APIs simple and few and in general. And then the second one is that you should avoid unnatural acts. Yeah, I know we've all been in that place where you're sort of hacking on a piece of code, trying to get it work and hacking on a piece of code, trying to get it work to work. And you go to bed and you get up in the morning, you look at the code, you're like, what was I thinking? Because you've done something horrible and unnatural. Let's, let's try and avoid unnatural acts. So. Never happened to me. Yeah, never, never ever. It's sort of like the running joke. I've often joked, hell is other people's code. Please note you were other people yesterday. Yeah. Okay. So maybe, maybe while we are here on this picture and also in relation with something that Andre mentioned, I had a discussion today with one person. I think that, that you, that you probably can, you will remember this PR where we were trying to have multiple Quagga routers interconnected in a mesh. If you remember this problem, in the examples, okay, whatever. Sorry, I was muted. I don't remember that specifically, but it's exactly the kind of logical thing that a human being would want to deal with the system, definitely. Yeah. So we were discussing and this topic of IP assignment, static assignments, et cetera, et cetera came up. And I think that that currently we are more or less bound to having IP over the connection. We're kind of requesting it each and every time, which should be probably changed. I haven't checked the code lately, but I think that it was, it was a thing. We are, we are a little bit, we are not quite as crisp in my recollection about being flexible with payload as the API would tend to indicate. And I think that's just a matter of, we've been a little overly focused on L three. Yeah, of course, of course. That's how we came to it, honestly, but we know we want to do better. Yeah. Yeah. So I think that, that at some point you have to think a little bit more about how do we want the IPs being, because what we have today is an IPAM implementation in the SDK, because that's, that's, that's where it lives today. It's, it's something it does its job for whatever we wanted to use it. But probably people would like to be able to, to assign IP addresses in other ways, let's say. Yeah. I mean, you could totally do all kinds of different IPAM implementations that are different than the one that we did in the SDK. I think the SDK one was done as sort of the simplest available. And I've even got some interesting thoughts. I've thought a little bit about this problem space as well, particularly around doing the L three domains. And it turns out like we have all kinds of interesting characteristics that make IPAM for us in the L three radically simpler than it is generally thought to be as a problem. It turns out that the things that normally make IPAM hard, for us make IPAM easier. And so there's, there's some really interesting approaches to IPAM that can be taken. I think that would be very powerful. You know, and I'm, I'm, I'm delighted to explore those as long as we don't like weld any one particular way. Anything else that folks would like discussed here or just drop it up and Yeah, I think we're all sort of fading back in. If anybody has other things they'd like to talk about that would be awesome. We have one of these rare meetings where we're not running up against the wire. So if you've got something you've been saving, feel free to bring it up or any questions as well. Okay. Well, if there is no further questions, it's last chance to unmute yourself by if you didn't unmute yourself by accident. If there are no further questions or comments for the agenda, then we will have this same meeting again, same time next week. And I want to thank everyone for attending our first one of the year. And here's to a fantastic year for for the community that's coming up. So we'll catch you all later. See you. Take care. Have a good day. Happy New Year. Bye, bye. Bye, Charles.