 If not, we can get started and I'll go ahead and read it off. Okay, so I will go and get started on the actual call itself, and if someone's able to get around to sharing it, that's fantastic. If not, also posting the link here would be good. So we have three recurring meetings. We have the NSM document meeting, which looks like it's been switched monthly. Do we have anyone from that particular call? It doesn't look like it. I'll reach out to Romkey and Prem to see what they are. Sorry, not Romkey. I already got to Jeffrey to see if he's up to running this at this particular time. Maybe we can switch the time around to a time that's more accommodating. But right now, I think he's actually on a vacation. So we'll work out when we want to run that. Same with the use case call. So I'll reach out to Prem and Romkey about it. We have the CNCF Telecom User Group, which occurs every first and third Monday. We just had a call yesterday. And there is a CNCF networking working group, which occurs every two weeks on Tuesday at 9am. So major events that are coming up. We have ONS in Europe. One more thing here, Fred. Sure. Sorry, Fred. We probably should update our minutes. So we have this morning at this European morning, we had the World Group Code, NSM World Group Code, which is in the Asia-friendly time zone. OK, time. So I don't know. Maybe we should just start it here also in the recurring. But the minutes are updated there just below this new one. So I might give an update later. Sorry. Cool. And add to the agenda as well, just so we can talk a little bit more about it. Yes. So we have three major events going on. We have ONS Summit in Europe. We have Four Talks Accepted, a Tug Meetup that's going on, Telecom User Group. And we have the CNF Testbed tutorial, which will be going on. And so a lot of activity. We have the Open Source Summit in Lyon with a talk accepted there by Ivana and Radislav. And we have KubeCon and CloudNativeCon. We're still waiting to see what the results for the talks are on that. But it's a huge announcement. We have a NSM conference, co-located conference, NSMCon, which has been announced. And the call for papers is open. So, yeah. So we'll have a full day of NSM related things. So definitely mark your calendars. The entry for it is $50. And those $50 will be donated to the, to the CNCF Diversity Scholarship Fund. So the $50 is primarily to prevent people from signing up for a free event and taking up slots and preventing people who really want to come from, from joining it. So the call for paper is, there's a form there or call for proposals. There's a form there. So it, go ahead and think about what you want to talk about and feel free to submit it in. And start with all your friends. And with that, we have the network service mesh Twitter account. Lucina, are you on? I think she is not. Cool. So. Yeah. So she, she announced it on Twitter, the NSMCon as well. So that's an easy place to, to find it. And with that, do you want to talk about the one a.m. Pacific time meeting that you've been running? So shall we just call it the morning call? Yeah. Okay. So today we had our first call. We should have an official name for it. But let's say that it's the be weekly morning call. It's your European morning, 10 a.m. Central European time. I think it's on the calendar already. We need to update probably some links here and there. We had quite good presence. I think about 10 people. So it's a 30 minute one. It was mostly about, you know, introducing the projects and talking about the status. We had a number of questions from some of the participants. And the intent is that in the following one, which will be two weeks, we'll give like the purpose of this call is to mostly allow people to ask questions, give suggestions like what would be, what would make sense and things like that. So on this call, it was mostly me talking about where we are, what we do, the purpose of the call, et cetera. But on the next calls, it will be mostly the floor would be for the people that attend. And that's about it. Nothing. I mean, I'm excited that we started it. We had participation. I hope that it will grow even more. Yeah, I think it will definitely grow. The key to it is being consistent. Yeah. And so there's, we definitely know there's people interested in that region. So as they find out about it, I'm confident people will start to show up and we'll grow ourselves a friendly Asian community. Yeah. Yeah, I'll see you about on occasions dropping by as well. Like the, I think the initial proposed time was something like 3 a.m. my time or around that time, but 1 a.m. from 1 to 2 a.m. I can occasionally do that. I sometimes up at that time. Okay. You're welcome. And. Oh, I forgot to mention on the NSM con. We are. We are also listed on the cube con co located events webpage. So if you go, if you see the cube con 2019 program. In the, they have all the co located events where we're listed there as well. So you can point people there and you can also point them to our website, the never service mesh. Website and we have it listed under events. And so we'll put some verbiage on the front webpage soon. So that is a to do item. But that we have at this point. So. And we'll, we'll share more information as, as time goes on. And so the one last thing we need is the call for papers itself as a. As a deadline for. For the proposals to be submitted. So that deadline is September 13th. And the schedule will be posted on September 27th. So we'll go, we'll, we'll add that to the, to the events page as well. And so since we don't have anything else that's on the agenda, there is something that I wanted to, to talk about a little bit. So. And Nicola, I, you'll have a lot more information than I will at this point. So we were having a bit of flakiness on the, on the bills. And with running the NSE is few. Do you have any information on that? So in terms of like what's going on or what's happened? Yeah. So. Apparently, on Monday, a new set of corporate services were announced and because we are essentially using just the latest upstream version of our builds. I believe were updated. The point of 115.2 was to fix two CVs. One of the CVs is regarding an, an authorized taxes to custom resource definitions from one namespace to another. We actually have an issue about it. We tried some fixes. We're still trying to figure out and to convince CI to pass all the tests. But the, essentially the fixes, the, the problem for, for now our site is that our custom resource definitions, you know, the network service endpoints, network service managers, and the network services themselves, they are all scoped to a cluster level. And we are accessing them with a namespace in the request, like when we want to access, for example, the list of network services. We're sending calls to the namespace and this fix specifically prevents this case. So there is a mismatch between whatever you sent in the, as a namespace in the request and the scope of the CRD then you get error. So this is essentially fixing cause security problem. And we are more or less exploiting it unintentionally. That's what it is today. So it sounds like the potential fix is just removing the namespace so that we access the cluster level instead. What we discussed in the main channel was essentially that it probably is a better idea to keep this and just make the CRD's namespace. So this will eventually allow in the future to be able to run to network service managers in parallel. I know that this is maybe a little bit debatable and probably needs a little bit more thinking. It's essentially just deciding on one or the other either. I mean, it's just deleting some code or changing names, nothing really special in terms of programming algorithms and whatever. I think that that's kind of restricting ourselves to have only a single cluster while NSM is probably, I mean, like if we can avoid it, probably we'll pay off some time in the future when we get more advanced features of intercluster and whatever features. In the short term, if we don't fix it soon, do you think it'd be possible to pin to 15.1? And the only reason I asked is that we have some people who are looking at it for the first time. Yeah, yeah, I know. That's the reason I asked. I also got some people, I also have some people that got to me and said, yeah, I'm trying NSM and it's doing this and I'm doing the wrong thing. I mean, yeah. Pining in terms of what, like having this in our mainline. Yeah, I mean, we can do that if that's not the only way forward just to make master green and people to test it, then we can revert it once this other thing comes in place. Yeah, and we can, and we can remove that on the branch for fixing so like the actual branch of fixes. Yeah, yeah, yeah. That way we just unblock people who are trying it for the first time since we don't have a, since we don't have a stable branch or something we can call right at this time. Cool, yeah. Well, this could give us probably we need to create different at least one sanity test pair different version of Kubernetes and put it into our continuous integration system. So just check all the possible version check master check release it versions. It should be pretty easy in current infrastructure. I think a good idea. Yeah. Do you think like nightly built or like weekly built or I don't know what do you think because if you want to add this in all our testing then I don't know. I mean, we are already at one hour of a full CI. But it will go parallel with the current just creating the master on packet with different versions probably could help to detect this kind of errors. Yeah. Because if we have a fixed version, we don't know about the master could not work with the latest version of Kubernetes. Yeah. Yeah, I mean it's the CI clearly is is working because we have on the latest Kubernetes we we found it. So it definitely it definitely helped. And so I think I do think that it would be good to test older older versions as well like for the ones that we support right now. I think this is which which version because essentially in this particular in this particular case because it's a CV I'm pretty much sure that everyone back ported. So there was a question on the chat. Why why AWS broke because I mean even if they're using 1.3 130 in seven. But I guess that they just back ported this specific part because it's a CV in the moment that is disclosed. You should be patched especially when you're a public cloud. Yeah, it's back ported to AWS but not Google. Wow, really? Get on Google. You have some free resources there. Okay. I don't know. I mean, especially with the public cloud, it's it's a bit tricky also also also given the fact that they also are providing a couple of versions for more than all like you have one 12 and one 13 in in Asia in AWS, right? You are able to switch back and forth between two different versions. I mean, if we have to be to be to be checking all the versions that are out there and that we claim we support or we should just figure out a subset and say we support this, this, this and this. And it's usually really a matter of just small API modifications. In this case, yeah, there was a security fix which I don't okay, I hope that there won't be much of this in the future, like, you know, every week or every month. I guess that that is mostly about just bumping the API to the next version and changing things here and there, like I'm trying to deal now with the web hook, which apparently changed quite from the last time that we used our plan go code. But okay. Yeah, I mean, definitely if if we have a PR and measure and see that it doesn't really hurt our CIA in terms of timing, then. Okay, why not? Let's let's do it. Yeah, I think something we can do in the meantime is like we're now it's better to keep it simple because we have limited resources. So, so it's that my recommendation would be keep it simple with the CIA is doing what it needs to do. So the fact that it broke on one on one 15 to is is excellent that we caught that. And eventually when when we're shipping our our first stable release, so we can work out and say, Hey, this thing runs on this version of Kubernetes as its primary. We've also tested it on on these versions of these clouds. And so we just we just say what RCI tested on in the beginning and then what we can do is in the long run as we get more resources. Best case scenario would be to get like someone in Google to help maintain testing with the Google cloud and someone from from AWS to help support and test AWS one. So that would be the best case scenario but barring that that we can save each other versions that we tested against. And when a CV comes out, we can we can make sure that it continues to to work with the versions that we've explicitly have stated and the clouds will have to play it by by year because we may not have the choice of moving up to a dot release. They may force people to move up to to a higher one in depending on their on their upgrade strategy. But for now my recommendation is keep it simple. We we fix the we fix the problem and I think temporarily while people I think doing a pending to an older version on main on the master I think would be okay. It's just but it's just so we can unblock people who are actively actively testing in the same for the first for the first time until we until we have that first table release. And then from then on will always point people to the to the table release. So. Okay. I'm cool. And with that, I don't have anything else to to bring up. I just want to make sure the community was aware what was going on. Yeah, we are. Do you have anything else? It's it's a it's a good good good occasion. I guess I am. Wow. Sorry, you you cut out what was that? I was I was just saying that it's actually a good good occasion to actually probably sit down and think a little bit more about how are we handling all these different versions because okay testing is one thing it's fine. But then our client client code for example is somehow stuck to 1.14 for reasons and we're not really able to move forward. At least not that easy. And then I'm not sure what other projects are doing. Are they following just the latest release branch? We also essentially we have three versions released 1.13 1.14 and 1.15 in terms of Kubernetes and are we tracking all of these? Do we need to build against different clients? Are they backward compatible for what's compatible even? I know that some of the APIs are but I'm not really sure how what is the proper way of being able to support all of these. Yeah, let's start. Let's start doing a little bit of research on it and we can add it to the specs board and say these are the upgrade. These are the version strategies that each of the cloud runs the version strategy that Kubernetes uses and that way we can have all the information in one place because to me it's not clear what these companies are doing but I know that they do something that's predictable or I assume they do something predictable. And so that'll give us the ability to work out in the long run how we want to do versioning as well and what we want to peg against. Just so we can have that initial information. Okay, that makes sense. Yeah, we definitely can and probably should handle this through a spec and just try to gather the information and do a little brainstorming on how to go forward. Yeah, because there's no way we can make a decision without that information. Cool. Is there any other topics that we want to bring up? I invite the community as well if there's any topics anyone wants to ask. Cool. With that I want to thank everyone for your time and make sure you start thinking about your NSM upon proposals which will be the day before coupon or the 18th I believe. And with that everyone have a fantastic day and we will see you next week at the same time. Take care.