 Could the person who just joined the call with the unintelligible string, please identify themselves? Yeah, this is sort of the swap. And this is Zoom? Yeah, I will try to log in myself, yeah. I just, just, you could, there's a rename button. It's just, with the problems we've had with some Zoom bombing, it's good to know that we're dealing with real people. Okay, cool. For those of you who are joining the meeting, I will put the link in the chat for folks to add themselves to the attendee list. And the, just a quick reminder, these meetings are recorded. They will be posted to YouTube. And we typically start about five minutes into the meeting. So we usually take about five minutes for folks to gather themselves. Let me actually, speaking of renaming, let me rename myself properly. There we go. So welcome to the Network Service Mesh Meeting. Please add yourself to the attendee list. We'll give it a couple more minutes and we'll get started. Fantastic. So I've put the link to the meeting minutes in the chat. If you could please go ahead and add yourself to the agenda. And not to the agenda, but to the attendee list. I mean, add yourself to the agenda too, if you have something you'd like to discuss. That's totally kosher. Okay, we are five after the hour. So let's just go ahead and get started. So welcome to the Next Network Service Mesh Meeting. This call occurs every Tuesday at 8 AM Pacific. We, Nikolai, are we still running the Asia-friendly polls? I know you recently switched to a new position. So is that something that's still running? Is he on the call? Because I think he's- I might not be, yeah, that's probably, that's probably quite the problem. I will reach out to him afterwards. So we tend to run one every other week, but we had Nikolai just had a job change. And so he's still working with the Network Service Mesh Community. It's just, I don't know if that time will work for Nikolai, but it is possible that perhaps one of our other colleagues in this community may pick it up. So anyways, I will work that out and I will report to the results back next week. We actually- Sorry, Fredrik. Usually on this meeting, join it only, sorry, and we didn't have our back folks. So I'm not fully sure if Asia call is so strongly required. Yeah, that makes sense. And so ultimately it's a decision for the people who are people attending for all of you if you want to continue it or not. And I know eventually once we have something on that's production ready and running and then people will definitely show up from Asia at any time. I have a question would be whether it's worth investing the time now versus investing. Starting at the time of investment, son. Cool, thanks for that information. So we also participate in the CNCF Telecom user group which occurs every first and third Monday of the month the first Monday at 8 a.m. Pacific and every third Monday at 3 a.m. Pacific. The next one will be two weeks from now at 3 a.m. Pacific time. And these times are going to switch over to UTC time. So we'll update these soon once we get the calendar on that. We also participate in the CNCF SIG network which occurs every first and third Thursday of every month at 11 a.m. Pacific which should be this week. A few other things. KubeCon China has been canceled. KubeCon Europe is now a virtual experience. And we are going to work out what's going on in terms of NSMCon. And so we'll have information on that soon. We have ONES North America which is happening on September 28th. And the ONES Europe and Antwerp is to be determined. We also have KubeCon, CognitiveCon North America which as of now has had no change in schedule. Just as a heads up, the CFP closes in June 12th which is just a little bit over a month from now. In terms of announcements, the webinar we put on last week in conjunction with the Stiffi and Spire and the HPE went really well. So definitely recommend taking a look at it if you are interested in zero trust. Social media community team. So Ashley sent a message that she was not going to be able to attend this particular week but she's updated the stats. And so we have 753 followers on Twitter which is an increase in three and we are following five more and we have put out 22 tweets. We posted call reminders, last week video recaps, the link to the webinar, a CNCF testbed event call, testbed call reminder. And all of these are linked in the agenda by the way. So if any of these are interesting to you then this is one place you can find them. The NSMCon, stay tuned for more info, virtual experience information, ONES information for Los Angeles. And we retweeted LF Networking, there was a, there's some media that LF Networking put out in plain words, you know. VMware open source, blog about to what the biggest barriers are for developers joining and a 30% off on certificate and training. I should like an advertisement now. LinkedIn stats, we added another person and post the same content as Twitter. And our plan is to continue on with NSMCon EU, promote registration, promote sponsorship, continue to show QCon schedule and continuing to promote NSM sessions at QCon, assuming there are no changes there. And so on the agenda, we have a new tool that is called to go and Ed will tell you all about it. Ed, do you have a part? Sure. Let me share just a really quick bit then because it's easier to talk with a little bit of text in front of you. So there's a set of standing problems right now that we've been hitting in spades, trying to do development of go in a doc, where you're trying to build Docker images with developer and go, particularly when you've got multiple repos. And let me go ahead and show the screen. There we go. And the reason I'm bringing this up as a tool I'm hoping will adopt because I think it will probably make our lives easier. So basically the basic problems are when you're using go and Docker together, first basically you get the redown load of go dependencies on each Docker build and you can sort of hack around that with putting this little ugly bit of stuff into your Docker file. But it's still a thing. Also, you don't get the binary object cache which slows down your Docker builds, which is annoying. But then this is the one, the third one here is the one that really has made life hell which is local go mod replace directives. Things like saying, oh, I'd like to replace, you know, I'm working on a command like command forwarder, the ppagent and I'd like to go hack a little bit in SDK. So normally in go, you just put a replace directive that redirects to the local SDK copy you have and life is ground until you go to try and build your Docker container and then you're completely screwed because Docker copies your local command repo into its context and it goes to do its build and it doesn't find your local copy of SDK and it basically doesn't work. And this is ugly and awful and terrible. And so essentially what all to go do is, you know, provide a drop in go replacement where you can run to go build or any other Docker any other go command you're used to and it will effectively create a local cache and adopt to go directory within your current directory that will be picked up by Docker. And so just by using to go instead of going your Docker file, then it works normally if you haven't used to go in your local host but if you have used to go on your local host then it goes ahead and does that. It goes ahead and uses that cache that got scooped up and then finally just as a convenience matter if you give it something that's not a go command it will just execute it after warming the cache. So you can literally just say to go Docker build it will warm your local cache on your host it'll then run Docker build which pulls that up and you get a nice warm cache in building your Docker containers. So it should let us build much much simpler much much easier much much cleaner Docker files without having to do all kinds of insanity. So I'd appreciate it if folks could kick the tires that would be fantastic. Sorry, and a great part about it is it literally follows the same semantics as the go build as a go tool chain. So you type go build you type to go build it's literally the same shape. It's literally the same tooling under the covers because under the covers all it's really doing is constructing the cache and then handing off to Docker but shifting Docker's go cache go path and PWD environment variables into the cache location. So everything is really being done by go under the covers. It's just a very, very light shim. You know, it's a very, very tiny amount of stuff that it does. So the hope is we can start using this in network service mesh fairly soon. But again, tire kicking would definitely be welcome. Any questions from folks about this or comments or? So one other interesting thing as well is this should also work on other platforms as well. So it definitely works on OSX because that's what ed develops on and then we have Linux support should be there quite naturally because that's what an SM is developed on it pals against. And so that leaves the only other area that needs to be tested out and you see if it works or not it's going to be the Windows environments which for the NSM community is secondary but if anyone has an interest in that space, definitely feel free to give it a shot and see it work. The Windows, just like Linux also has the capability to create hard links and that's the only requirement is that you can create links in your file system. And so in that scenario, it should be relatively straightforward to get it to work. Cool. So in terms of agenda, is there anything else that anyone would like to discuss? Okay, so I have one last item. So I've been working on a set of examples where I've been working on a example for the SDK and the new SDK and helping develop out the last portions of the SDK to get a full working something that works and to end in that environment. So in the near future, I will have some working information on how to develop against the new SDK which will include information on how to develop new network service endpoints and information on how to contribute to NSM directly. Interestingly, the overlap between network service endpoints and NSM itself are now extremely similar. The network service manager and network service registry all end up looking like the work service endpoints in terms of their APIs. And the SDK has a very clean way to propose these various services together. So we will have more information on that and if you know how to develop a network service endpoint of which there's a very basic pattern to do so, then that means you can literally create functionality for internal NSM without having to know about how everything works internally. You can focus on the logic of your application in a very tight vibe and the system will compose nicely with the rest as long as you follow certain patterns. And those patterns will be documented in more detail as we get to report. Well, I don't have anything else. So if there is nothing else, then we will conclude. So last call, okay. Well, thank you everyone for attending and we will see you again at the same time next week. Take care. Bye. Bye.