Hey folks! Quick mic check. Can you hear me? Yep, we can. Yep. Give us a few more moments for people to hop on that we'll get started. Also we'd like someone to share the agenda that'd be fantastic. Head and get started and I see a couple people are filling out the agenda as we speak so feel free to do that while we begin. So welcome to the network service mesh weekly meeting. So we have this meeting that occurs every week on every Tuesday at this time. We also have before this a meeting at 4 a.m. Pacific time. Sorry that's the same correct one. There's a there's a version of this meeting. Do you remember the time that it's on? I think it's 10 a.m. CET. Yeah it's 10 a.m. CET 8 a.m. GMT if I recall correctly. What are the quick reminder to folks who are on the call? There is in the chat a link to go and add yourself as an attendee. So if you can go ahead and do that that would be great. Yeah we can have someone share the agenda that'd be great so people can also follow along. And check the meeting chat for the location of the meeting notes where you can add your name down. So we have we also participate in the CNCF telecom user group and that occurs every first Monday at 8 a.m. Pacific and every third Monday at 4 a.m. Pacific time. The zoom is is linked in the in the meeting notes here. We have the CNCF networking working group. I think those have been on hiatus for a moment but I noticed just today this this morning that there is now a CNCF networking SIG that is being set up so I think that's something we should probably we should probably pay attention to. Well that that's actually quite interesting. There had been a CNCF networking SIG but it sort of wound down after a while and was not didn't have a whole lot going on there. So yeah there there's a brand new draft charter that I saw linked today. Oh that's fantastic. So I have I have not had time to read it because I just saw it like 10 minutes before this call but yeah it's it's it's in there. I'll find the I'll find the link later on and I'll I'll add it on. Major events so we just finished up ONS Europe and so overall I think it went fantastic. We had multiple talks and me and Taylor gave a interview with Telecom Music Group and I also had an interview with I forget the name of the of the group but there was a person there named Swapno and I'll find the name of of his particular group later on as well. So we had a lot of really good of really good participation in ONS and there was a lot of excitement about it as well and there was also some interesting news from Dan Cohn. Taylor are you on the call? I am. Are you able to state what Dan Cohn mentioned up on his keynote? Sure. So you're referring to CNF testbed and kind of where we could go potentially? Yeah since we're talking about ONS and in this particular one can you can you just give like a quick verb on what was mentioned? Yeah so we've it was kind of talking about where we could go with the CNF testbed and which is adding on to the roadmap which folks may have may or may not have seen but we ended up doing a tutorial based on where we are now on the CNF testbed which dealt with how you could reproduce the environment as well as burning different use cases. Someone is sharing their screen and they're not sharing the the dock anymore. So we we dug into that some and and the tutorial was based around what we're what we have now and we're moving towards kind of the next version of the testbed and and what Dan had mentioned was potentially using it as a dev platform as one portion so folks could do development on whether it's network functions or use cases, different things. This expands on where we've already gone so this is a good path. There's a lot of effects that are already using it for some of this and make sure that we get enough feedback to make that useful for more people and then the other part was around certification how we would be able to run certification and testing for to see if if whether your technology or the network functions or whatever are following cloud native principles and what does that mean. So those are the two main things development platform and in working with some type of certification being able to run the certification test. Cool thank you Taylor. Yeah there was definitely some interest in the CNTT meeting after ONS as well in this particular area. It would be just some feedback for you so it'd be good to make sure that the messaging on on what you're trying to certify is very clear because if it's going to be an end-to-end certification process we'll get a lot of pushback but if we make it clear that it's just specifically for CNS best practices and principles then I think we can get some really good we can get some really good traction there. Cool we have a CNCF webinar series that's going to go on tomorrow at 10 a.m pacific time so that'll be between me and Nikolai. I think though is there just the three is there anyone else going to be involved. I think it's just the three of us yeah and we've got a ton of interesting stuff to talk about there so yeah it should be quite a good quite a good time. Yeah there's a brand new slide deck attached to that as well with some really fantastic information so we'll make sure that that gets posted around. We have open source summit coming up in Leon with an intro to NSM by Ivana and Radislav and that'll be on October 20th through 30th. We have November 18th through 21st we have KubeCon North America occurring in San Diego with NSMCon so have we posted the agenda yet on that? Yes we actually have hang on let me if someone could go and grab the schedule and paste it in there we go thank you. So yeah that that's that is a going thing now so thank you to all who submitted talks they we had a lot of excellent talks submitted. It was great fun going through this election process. So we have that coming up in the first I guess the first day of KubeCon or the right day of before KubeCon depending on your perspective and finally there is a Kubernetes forum did anyone submit anything to the Kubernetes forum for either Sol or Sydney? No but there's one thing I do want to say about NSMCon which is make sure you register. It's filling up fast. Oh yes definitely make sure make sure you register that is true so we have limited space as well so that's going to you risk not being able to get in if you don't register now. If you've already registered for KubeCon in your registration email there's there should be a link or a reference number you can use in order to in order to add it on. Okay and with that we back to the question did we had did we get any talks or submissions in for the Sol or Sydney? I don't think so does anyone know of any? So considering the CFP is already closed you know as interesting as the information will be inside of it I think we should probably remove this. Yeah I think so too. There we go. God knows we have enough of this stuff already. Oh yes and we have so with that we have the social media community team so Lucina you have the floor. Hi good day great um so last week we were at Popin Networking Summit in Antwerp Belgium and gained 19 followers on the nServiceMesh twitter account followed 48 folks and tweeted and retweet almost 70 new posts. I posted about the webinar happening tomorrow the NSMCon schedule reminder of today's two calls the biweekly call and the weekly call and posted reminders and photos from the ONS talks and my plan for this week is to send another reminder for tomorrow's webinar and promote individual sessions and speakers for NetworkServiceMeshCon promote the sessions at KubeCon send a reminder to register to NSMCon and a call for sponsors and to thank and promote any existing sponsors and then promote those sessions at Open Source Summit in Leon. Are there any other items that you would like to see shared on nServiceMesh twitter? Yeah that's what comes immediately to mind for me but I mean we're still growing five percent week on week which is insanely good in terms of number of followers I just want to call that out because we're just killing it on on social so thank you so much Lucina. Thanks you're welcome. Yeah I can't think of anything else at this particular point once once the interviews end up being posted on between Taylor and me then we'll we can share those out but I don't know when those are going to be posted because I noticed that the ONS North America ones seem to trickle out between June and July so there might be a little bit of time before they pop out. Do we know if we're going to have any videos from ONSEU that we can support people too? No unfortunately I did not see any video recording equipment with the exception of the panel. Okay so the only thing that I'm saying is the keynotes those have been released and yeah I don't know of anything else like Frederic's saying. Okay yeah there definitely was not recording equipment in the rooms that I was in with the exception of the of the panel so would they have to um the panel that Taylor and I were on by recall seeing a video recorder there. There is a playlist that's out for the keynotes I didn't look through the entire list to see if the panel was on that but it's possible Frederic that it's already there if that was released at the same time. Yeah what they did last year was that the sessions that were recorded they stuck them behind a paywall and gave access to attendees so we may not be able to share it out publicly even if it's even if they do stick it up somewhere but I think what we should do is we should probably reach out to to LFN if they do that and ask them if they'll make an exception on this one. Yeah so one thing that you wanted to I'm not sure I see it in the list here we are supposed to have uh committers like interview or webinar I don't know what it is Ed. Oh do you mean the podcast for the contributors? Yeah yeah yeah I don't know when that's going to broadcast yet I think we're trying to record it in the middle of October and I'm not sure exactly when it will be broadcast but there there is a the folks who do our native podcast are starting a new podcast that's called The Contributors and so they are yes they're they're they're interviewing us for that in middle of October and hopefully that will come out before CubeCon so cool. Is there anything else that we want to talk about in terms of social media stuff or should we move on? Okay with that let's talk about CircleCI. Yeah so if anybody's pushed patches this morning or been looking at patches that have come in this morning CircleCI is currently having an issue and is broken this is purely a CircleCI problem but in in typical fashion they are right on top of it so they've already been in communication with me so let me know that they're working on getting it fixed so we expect that to resolve pretty quickly and like anything else every system has a failure rate you know but they've been really really good about you know closing the loop quickly so hope to have that back up shortly. Cool sounds like they're engaged and so let's make sure that we have something in place so that we can retrigger builds that need to be re-triggered. Other than that feedback from Asia community call so Nikolai I believe you were writing that one so. Yeah we didn't have any like China time zone you know Asia time zone turnip this morning so we used it to go through some internal topics mostly so I left just before the end so I don't know how it continued but in the beginning we went quickly with Andre to do some things then we spent a lot of time with Ilya on restructuring the make file system and these new ideas that are there his PR and then Matt came up with a couple of questions and updates which Matt if you're here maybe maybe you want to tell your updates what you're doing with Michael. Oh yes we have been working with Michael about the capabilities to inject physical NICs he's doing so in the CNF testbed and I've been testing it and we are discussing how we can leverage the the device plug-in framework to be able to overcome some some VPP DPDK issues because for now if you if you use some VFIO devices each container has to run privileged and see all the FIO devices so I know that we've solved that in the past so and I don't know what's going on currently in the SRIO DPDK device plugin but there's a there's a chunk of extremely old code that's probably not directly usable except as reading material called the SRIO V controller and I know for a fact that that that code had been run and injected into an unprivileged pod everything necessary for a user space program to run unprivileged an unprivileged pod to pick up that VF and use it that said there's also a set of issues with DPDK please note this was a year ago so I don't know if they were talking about fixing them they may have but when I last looked at it there were a set of issues with DPDK whereby if it did not find it if it did not find itself in the numazone it wanted able to get all the huge pages it wanted and able to get exactly what it wanted it would just crash yeah now with a really pointed log message so it's not like an unorderly crash and say I can't help you I'm done but that was a DPDK thing not an SRIO VVF thing the VF pod works even with like unprivileged containers I think the issue I'm seeing right now is that VPP just doesn't want to start when it's not running privileged and it's both due to huge pages and the kernel module for VF IO PCI so the device plugin itself works but it just doesn't work well with VPP or DPDK yeah yeah so I can if we can figure out whether it's DPP or DPDK at this point I can try and point the right folks at it from both sides because I think it's all in our all and everyone's interested to get this resolved but I think right now it's probably mainly VPP since VPP is doing some passing and if it fails then it either crashes or it just goes through like a default where it doesn't really care about the devices you just finish everything if you can if you can gather that stuff up I can probably get someone to go take a look at it sure sure so um no but that sounds great Matthew um you guys are doing amazing work and that that's super neat stuff okay then the other issue we are we're talking about this morning was another VPP issue about the metrics Ivana you're all aware of what what's happening here yes I was just going to raise that Matthew asked us in the morning about the VPP metrics and I checked the issue in the legato repo so they agreed if FET remembers you ask them they agreed that they will send metrics so the VPP agent but make them configurable and currently there is no movement on this issue so I think if we want to prioritize that it's not priority for them so maybe if it's priority for us we should move it forward let me let me also check and see where that stands with them um because I know those guys pretty well and I talked to them and they were they said they would get it done but they're also like you know how some people just don't talk very much um we have this marvelous word in English for this called taciturn all right it's how you describe someone who just doesn't really say much um and they tend to be taciturn people the guys working on the VPP agent so they could be busily working on things that it didn't occur to them to tell us so I will definitely check in with them and talking more about metrics observability uh this last week I was more focused on the ONS demo where unfortunately I couldn't attend for some issues the conference but for the PRs are not yet updated and I will be able to update them at the end of the week because we have another conference and the Prometheus PR and the other PR for Exponing POT names these are the two that are required for the metrics observability and I need to update them with latest master and test with master okay yeah and feel free to reach out over I am you you we've we've gone multi-module since that since you probably last updated those um which isn't hard but if you bump into anything it probably the fastest thing to do is to ask so uh I was having another question related to to uh the open networking submit unfortunately I didn't attend the the submit but uh I don't know if you had some contact with vnf vendors interested in leveraging the the NSM framework which uh which group was it no uh not uh not uh specific vnf vendors but in general did you have contact with with vnf vendor interested yeah I apologize it's coming across a little bit poor quality on my side so the question is do we have contacts with some vnf vendors yeah because the submit is a place to to discuss with them and I'm interested in in having a proof of concept with a with a with a vnf so uh at least from if I if I might take this fret maybe maybe you have a lot more to add or I don't know maybe something some things are not to be discussed but so uh I was uh I think much I told you today this combat is probably worth also talking about this now so I wanted to talk where some guy had developed his own framework to simulate large networks uh his demo was based on quagga essentially running a mesh of quaggas like 750 quaggas meshed uh in kubernetes uh and here is actually joined our channels so I spoke to him and he agreed that we might try to figure out something that can be done in our example's repo that can replicate similar things and the other thing that happened that okay I forgot what it was there was something case eroslav do you remember not sure so about running some something in the scns yeah okay I it slipped my mind so fred if you if you have something that you can tell yeah so out of the ones that I that I recall so um I feel like the number of vnf vendors that were there was not as high as it would be within like the north america one so I mean you had some of the larger companies that has their that has a lot of uh of pull in from from a variety of places like you know ericsson and similar uh and I did have some conversations with uh with uh with them uh interestingly though the the most most of the people I ended up talking with uh in when I went to the cntt event were primarily people from the from the operator side so uh so the operators are definitely interested but uh yeah I felt that the participation from the nf vendors to at least from from my perspective seem to be uh seem to be lower than usual so that's which limits some of the conversations there I just remembered what I wanted to say so Taylor is here on the call and Michael and other participants that that are doing uh this wonderful cnf test but so on the on the roadmap for cnf test but it's an interesting demo with kind of 5g gateway gsm 5g gateway uh and I don't know if there are specific plans but I would assume something probably based on porting omek on top or something like that so if guys are interested in this probably we can try to form some form of I don't know special interest group I try to push this through I don't know but to me omek is a 4g only it's not 5g okay okay I don't know that I'm not sure but some colleagues told me that uh huh yeah I guess it is 4g only but it has like uh that uh cpdp split so uh in a way uh you you you have like a upf functionality there right so it's like in transition kind of a gateway uh that's here um that's Dan from bell um I haven't done the discussion that I was I was not at the onus last time but from my conversation with a lot of the vnf vendors we currently use right now my guess feeling is they're not even at the discussion of should we use an sm or not they're just trying to figure out how the heck do we containerize or make our application cloud native and how do we sell them to us and that's the resounding sound I've seen right now is that and that's part of I think why the telco user group and the white papers don't need to be app app fitting faster than we talk we think about is because that's where the day we have a kind of an architecture around this and people start building code to do those things then it's actually makes it more prevalent why should we use network service mesh or not right now that I think yeah little yes yeah it's exactly my feeling on it as well like um one of the things that I mentioned in the cntt group for the people that are there was um like there was a lot of a lot of talk that was centered around how do we containerize that how do we containerize that and uh so one of the things that I uh brought up was to keep in mind that containerization and cloud notification are two different things and that they need to talk about them as separate things where except for cloud notification requires a good containerization story so they have to get that side of correct on the infrastructure first but when they engage with the with the vendors and they start talking about they like to push their requirements and so when they talk about the requirements that's something that that I'm hoping that we can get them to do is to add in the the various principles of cloud native network functions that that we can help drive that particular that particular part of the industry for it but I think in the beginning we're going to see a lot of lift and shift and that may be okay for for some things but you know it's definitely something we're going to have to that we're going to have to educate and help and help guide people on so in one of my conversations I don't remember where it was but someone told me yeah there is this tool that you just throw VM at it and then it gets you a container like extracts everything and then runs and uh as you can imagine the essentially the contents of this virtual machine came from just like compiling more or less you know the bare metal images of what did exist so it kind of starts to creep in into the cloud native world if you think about it so I don't know maybe oh yeah just wait till you start adding things like cube version to it as well like people say well it runs in a VM controlled by Kubernetes and so uh but they don't gain the benefits of Kubernetes beyond a couple uh beyond a couple minor areas so it's we definitely have our work cut out for us in this education process yeah the other thing you're running too is that these tools that convert VMs into containers um they're only really operating at the level of user space so in addition to all the inefficiency that comes from the conversion because you get these giant containers if you have anything going on that actually involves like KLMs which most most vnfs do these days then it will not work for that purpose so is there anything else that we want to talk about on this or should we uh jump back to the agenda cool um let's talk about uh buzzing sorry i was at fredder i was me trying to respond this taylor um if we do have network functions that we can define whether one was the mention was a 4g type of network function versus 5g i think it would be useful to have the functionality um and the specifics of how you would test it from the outside if we can get all of that defined and that's helpful along this path um we're going to keep educating people on all the principles and stuff and and then how you could implement those using something using network service mesh or whatever um but along with that just having examples of code we've we've been lacking on that side so what what do people actually want and we didn't get a lot of feedback as mentioned from vendors on the specific network functions for whatever reasons um we did get a little bit at onus so from operators um including a one from swiss comm that probably be talking about after getting a little bit more feedback next time but if you have specific network functions that you can point out and go we can't release it because it's proprietary but we can we can give the specs on how it should work and the functionality uh we could end up writing in the end test and reimplement it ourselves yeah that's definitely an option and my my preference would definitely be to get the vendors to to jump in and buy in and help us with writing those tests out but I mean that that is definitely an option that we that we have is to try to work out what uh where we think things are going to be going and what uh what's considered to be of high value and just help defining what that particular path would be so that that is that is definitely an option um do you think that that would be a good area to drive through the through the telco user group I do I think yeah I agree I think um it it is a good place to get a lot of feedback and and then from there it can go to other projects so maybe network service mesh says okay we um see what y'all are trying to do we're going to implement some functionality to support that and then on the CNF test bedside okay we're going to um create an example with different pieces that are available and so on but it'd give a place to talk and then and go out to all the other projects and probably have um it'll be it'd be I would think that we could get to usable documentation papers uh paper uh then the white paper us uh the white paper is trying to cover so much and I think that's why it's it's been a lot harder but if we can get something smaller like this get people to jump in from vendors and their experience and operators and what they've been saying um we could generate those maybe maybe have a spec spec documents or something cool so I would like to sort of move on we got a bunch of other stuff we're trying to go through today yeah I completely agree um yeah let's go ahead and talk about this later on as well we can discuss in private how to how to engage great so uh fuzzing bugs yeah so just a quick note um we've been getting some fuzzing bugs some folks from the fuzzing community showed up and have been kind enough to run some fuzzing testing and so um as they've been finding things we've been adding bugs for them these happen to be an amazing place to start if you're in Kubernetes because sorry if you're in network service mesh and wanting to pick up a shovel and do some work um because effectively at the end of the day they're really easy bugs to fix um and so I wanted to be prompt people's attention to them it could be an excellent opportunity to get your first commit into nsm if you haven't done so already absolutely cool so the links are in the agenda um with that status of the project so let's jump straight into that yeah I wanted to have a brief discussion about api stuff just so that we can socialize some of this a little bit and get input uh so I've actually got a separate deck for this because in talking to Nikolai this morning he suggested that I draw pictures um and you know what happens when you ask me to draw pictures should I be saying whatever this deck is 90 slides I was rushed for time this morning so not quite uh so basically 45 talking currently about the current state of things so we have this remote local api split we have you know the the remote network service mesh and the local network service mesh api we have remote connections and local connections we have remote mechanisms and local mechanisms we have remote monitor connection and local monitor connection and this was done for relatively straightforward reasons in the early days of network service mesh but it turns out that having two apis for everything even that are very similar is actually creating a bunch of internal headaches trying to make the total system simpler and easier to maintain for people um and I think we figured out a better way of doing it so just to sort of drive through the particular so you can see how much they're the same this is side by side the remote network service mesh and the local network service mesh and literally other than the fact you're talking about local versus remote mechanisms they are exactly the same api when you look at connections they're very very similar the only differences are for remote connections we talk about the source network service manager the destination network service manager and the network service endpoint name and it turns out we've already got people asking us to get the network service endpoint name into the local api as well so these are very very close um the mechanisms right so remote mechanisms and local mechanisms structurally they're identical the only difference was the emum types and we already have an issue out requesting that we change from enums to strings for mechanism type in order to allow for easier extensibility and then for the monitor connection likewise they've both got connection events types that are the same the connection events are structurally the same the um monitor connection call differs only in whether you have a scope selector where the scope selector lets you say whether you're wanting the you know basically the the source and destination end of what connections you're interested in and so these are incredibly alike and it's creating all kinds of complications inside the implementations to have them be separate at this time um and so as we're doing a lot of refactoring the idea came up to bring them together and so the proposed state is that we do this we take the local and remote versions of these and we unify them so instead of having local and remote network service apis we just have the network service api same with connection same with mechanism same with monitor connection to give you some idea of what that would look like in the case of the network service where the two apis are basically the same other than the local and the remote part you just end up with a network service that is structurally the same only you're dealing with unified things for the unified connection object essentially you know you've got the remote and the local the only difference is you bring those together as a single connection where rather than having the source network service manager in the destination service network service manager we just have an ordered list of network service managers this gives us a little bit more extensibility and then you have the network service endpoint name which people already wanted for the local connection anyway and then on the mechanism types people are already requested that we move to using a string type to improve extensibility because there were people wanting to be able to add mechanisms without necessarily having to update the email and so with the mechanisms what we've really done is to make this all doable is we added a class to the mechanism that class being either remote or local the reason the name here is CLS instead of class is because all kinds of comedy ensues in languages like java if you try and use classes or as a variable name but effectively this is either remote or local and this way we can tell the difference between the mechanisms we're dealing with because you should be able to tell the difference but you don't have to have two separate objects for them anymore any questions so far okay and then get good no i was saying nope it's clear and then for the monitor connection where we had the remote and the local we would unify those down to a single connection monitor where we would simply have everything have a monitor scope selection and have a repeated list of network service managers just like we went to a repeated list of network service managers in the network service request for you know for flexibility and then everything comes in with a monitor scope selector and so what i'm hearing is we effectively half tower api with these particular changes yeah yeah absolutely and then obviously there has to be a transition plan for the shift and so the thinking was that we go ahead and create adapters to the servers so that we can switch over to the new api and simply wrap the original server code um rather than having to try and rework all the code at once and then anywhere in the original server that we're using clients and this is true for either network service endpoints or network service managers we have an adapter for the client so the original code if it thinks it's calling a local client for the network service management api um it just instead of instantiating that from one place it instantiates it from a compatibility library and that ends up wrapping the unified client call when making the call to the the out and so in this way the original server code only changes in using the client adapters internally at first and we wrap them around around them in the service adapter and then we can at our leisure pull the pieces out of the original servers into things that use the unified api in order to complete the transition this should let us switch to the new api fairly quickly um and then do the transition in a more leisurely fashion so we don't get giant prs that change everything all at once and to give you some idea of how that flow would go you know essentially the stuff that comes in now to any of the servers would be the unified api yet we get converted to either local or remote coming in because we do have that mechanism class to be able to tell that then calls whatever the original code was in the network service manager or network service endpoint which does whatever internal processing it was doing before uh it then makes its call out via whatever clients it's making which goes to the client adapters they convert to the unified api and they use the unified api going out and so this should allow us to do a fairly quick transition and then deprecate the old api on the internal old original internal code um as quickly as it happens to go but it doesn't have to happen in one piece it can happen step by step in small pieces so i wanted to sort of come here talk to you guys about it see what people's opinions were um socialize this etc so we can have a discussion about it before we sort of proceed it i think the one thing we need to do is to make sure that any groups who have been trying to build things on top of nsm that we just give them a heads up and the only one i can think of is probably lumina i know that they've been working with nsm for for a bit now uh prem company yeah if we can let them know and you know and anyone else you know of who's building things on top of nsm please let them know um this you know effectively you know the part of why the deck is here is to sort of help explain what's going on there's also in the meeting minutes a link to the pr um or that that's actually working on the new api if you want to sort of see the walking intactly it also has the start on the converters and adapters as well um but yeah do let them know this is happening but the one of the reasons that i'd like to get this done um if folks think it's a good idea fairly expeditiously is the the more time passes the more people will be building things on network service mesh and so you know we don't want to have we'd better to switch the api like this sooner rather than later yeah i completely agree especially as we do the march to the 1.0 release and so i think right now is the perfect time to do it and yeah we just go and get it done like this has a series of other really nice uh a really nice property so that once once we start to bring in things like uh multiple multiple data planes at the same time where like you could have vpp as a data plane your srlv uh thing can be a its own data plane or maybe have some of the controls in esoteric tunnel type that's not supported by your by your common infrastructure so it it'll help with like the dynamic selection of these type of these type of things and so this api change really helps simplify that entire that entire process um with that um is there anything else we want to talk about on the api discussion cool we have a few things that landed uh recently ed do you want to continue we have about 10 more minutes sure so i'll let ilia say a few words about the spiffy spire stuff that just recently landed uh that that's been coming for quite some time so it was it was good to get that in hard yes uh now zin and sometimes it has some troubles especially locally and a guy's from sort reported to me so if you have such troubles just i think means luck and but uh i think now it's already better it had troubles with kind but we fix it so yeah i i don't see any problems with spire yeah so we we did hit an issue with kind that turned out to be an interaction between kind and spire uh and so we currently in the repo it's it's the spire stuff is off by default but i think if we we we have a fix we should probably look at re-enabling it by default because we do want to move to a stance where we're secure by default the other thing that came in was a comment on one of the pr's from someone who said that they were having some issues with the interaction between spire and not and non-docker cri's um so i i'm trying to find out what cri they're playing with and what's going on so but they they're comfortable they have a workaround so they can they're not blocked but we obviously want to make sure we work in general so just just a quick kind of overview this security is not on the data path like it's not kind of we're not encrypting the links between the the different posts that we establish that we maintain it's on the g rpc level where the clients and endpoints talk to network service manager yep it's the it's the g rpc level exactly as you said it's the it's effectively an nsm version of the control plane um just to make sure for example that you know who asked to connect to your network service so that as a result you can decide whether you want to let them connect to your network service um or if you're a client and someone says has come back and said hey you know i've given you the network service um you can decide whether that's someone you trust to give you the network service and so forth and it's completely optional you can turn it on and off depending on your use case of course we want to move them all the way by default it's on but still you have the option to yep you absolutely have the option to turn it off um and you know hopefully we'll transition uh relatively quickly from it being default off to being default on good cool um the other thing that landed and this was mostly artem was a switch to a multi-module main repo and this essentially came about because for those of you who've been following along at home have probably noticed that the main network service mesh repo while it's not very large from the point of view of number of lines of code um it's gotten really bloated thematically the number of different things that live in the main repo is kind of large and there is a desire to try and break this up into sub-repos over time and sort of the first step for that was to have multi-modules in the main repo um this also helps a lot for people developing network service in points because it means that you only have to depend on the bits that the SDK itself actually depends on you don't end up pulling through like all the k kubernetes dependencies that are only used in the k8th directory for example uh that i mean if someone wants to see a demonstration of how this works in the examples repo i mean it did a set of patches to migrate to this new model and one can clearly see how the dependencies are not each and everything in the world but just whatever whatever is needed yeah that was that was that was fun um cool and then the last one on the various SDK updates um this was something that i've been doing i've been doing little tiny cleanups and um i noticed when looking at Yeager that they have this thing where for the Yeager configuration you can simply call from env and it will generate a Yeager configuration object from the environment and then you can pass it on down the line and we had been using an ns complete call which was and so switched to having something that was a little bit more conventionally named um but then the other one is to have the configuration passed in um at the top instead of completing somewhere in the middle um seemed to make a lot of make things a lot clearer as to where various values were coming from and sort of how things were flowing through well so we have about three or four minutes for the in progress stuff is there anything that we want to call out on that or should we punt that uh and revisit it next week i would be okay revisiting next week much of the stuff is stuff that's been in progress for some time i would i would i would like a quick update i didn't know that this thing exists what is the internet context story oh so this was a response to a bug that we found for auto heal and the bug was that when we were testing auto heal um we would start getting you get a few ping failures on auto heal and what it turned out to be was it was an arp issue so basically when you auto healed you were getting reconnected to somebody who had a different ethernet mac address on their um have a different mac address on their end of the connection right because you just reconnected to them and so you had a now you have an incorrect arp entry in your arp cache and so the the way that we're looking at fixing that is to add to the connection context just like we have an ip context to the dns context to add an ethernet context so that when you go to auto heal you can say look i'm auto healing the guy on the other end of this connection i'm auto healing is going to expect you to have this mac address over here could you please have that does that make sense yep yeah with this i was i was i was thinking something along the lines if you remember like i don't know two calls back or three calls back we're discussing that today ip's are more or less mandatory in the way that we have our ip i implemented uh but yeah that's probably something that has to be tackled separately okay well i mean like they're definitely not mandatory at the level of the api and if they're okay you're showing up as mandatory at the level of data planes we need to fix that yeah i think it's it's the data planes or the forwarders that actually okay we we definitely need to fix that if the forwarders are requiring it because they shouldn't be um i mean it's another thing if we happen to have very heavily encouraged that kind of behavior with our stk but you just as you observed you need to be able to run without um an ip context just like we also need to be able to run without an ethernet context frankly um so because you you you you're there are definitely use cases where you actually don't want ipan um happening so cool great well i think we've hit the uh the end of our useful uh time in this particular meeting so is there any last callouts anyone wants to say in the last minute or two okay i'll make one call out then i've added the cncf sig network charter that's being worked on to the to the uh to the list or to the to the agenda near near the top um the document is dated in april 2019 but there seems to be quite a few people looking at it right now because of the email they just sent um and it was written by leigh calcote with uh contributions by matt quine and ken owens uh and we'll leave it at that and uh revisit the stuff next week uh anyways uh thank you all for your time and we'll see you again at the same time here next week take care bye