 just run yeah so give everyone maybe five more minutes or so to to settle if everyone wants to go ahead and add their there we go look at that John's adding his name in if you want to add your attendance on the the Google doc which I can post into the chat here just to set them grab the URL just to make it easier there we go the mad frenzy as everyone overwrites everyone else to enter their names at the top wow I'm seeing hotmail I used to be a big fan of hotmail sometime back the critique is is our vintage contributor here I thought you were steampunk but sure that's true you know it's it's more of a you know all the gears and wires and everything decorating your clothes and that kind of thing better and I sent you a quick link to the poll for the review comments so once you're fine you can probably publish it not sure whether you got that in just the time I got to it it was so close to the meeting it seemed like yeah about it here because I think the the fundamental thing we're trying to get a sense of is you know is there literally no time that can work and it was which case we go back to the drawing board right right so cool yeah and frankly that that item has been on the list for a month and last week I had suggested that this was the this was its last chance to be on the agenda I saw your comments and I thought probably let's probably have some momentum to that is what I thought and then it created a Google dog yeah good talent sorry poll yeah well we'll totally we'll totally get to that I think we've got an item in the agenda so cool does someone want to drop a reminder in the IRC channel just in just that's a good plan that's a good plan hang on yeah yeah just to just to give everyone a chance there I have too many IRC channels I know well second let me get the right link are we missing anyone specifically yeah but I don't see Frederick here yeah let me let me call some folks out here if I call you out and you are here I'm sorry cool all right well I think we should get started so I think we will uh so if you're not looking at the the Google doc with the agenda and everything I posted it into the chat for the meeting it's also directly on the network service mesh repo website excuse me github page as well so I think we usually like to start with uh as Ed likes to sort of petitiously call it agenda bashing so there we go so feel free to scroll through I think today we'll cover AIs from last week we'll go through recent development activity use case map mapping the last the last time we'll see meeting time planning on the agenda action items within a conceptual review if anyone wants to add anything feel free to speak up now or if you do add something definitely mention it now so we you know so we can get there okay otherwise I think we'll just jump right in and we'll kind of review action items from from last week I see Frederick has joined all I did was I just went through last week's meeting minutes and I just grabbed the action items in the order that they were that they were mentioned in the agenda so there's so so Frederick you had an action item to enable the wiki and github and documentation there is there is there any update on that so the wiki is online there's nothing on it yet so we need to start populating it and also I was thinking about it while I was enabling it a thought came to mind the thought is that perhaps like we we do want to keep some information on the wiki but if there's something that's version specific like that's part of the question how do you use it or api specific related stuff the maps are probably go within the repository as well because if someone's using let's say we have like few versions that that are that are in use to say version like one and version two that are not really compatible but people are billing on top of them and api and version specific documentation so so I think that we're still we're still we need to have some documentation on the equally as well but for the main concepts I think that the main concepts and and the information about like how does how does Kubernetes like how does how does crd's work or so on you know I think that that information can live in the main in the main wiki things that are cross cutting across so those were my thoughts on it but that's definitely good hey Billy McFaul could you mute yourself please there is like a giant fan running in the background that's cutting out thank you so much better yes yes okay so I think I I I totally get what you're saying Frederick and and I I definitely I definitely agree with what you're discussing here yeah my experience has been in this this you know basically we're at the right point frankly for what we're doing right now which is wikis are really easy to edit and so they're great as you're just trying to document it as you get going um as as projects mature wiki's turn into terrible actual documentation and so you know eventually you get to a point where you do real real adult docs for the project but I don't think we're quite to the point where we need to put energy into that right now and so wiki is probably the right way yeah we can always migrate as well like it's absolutely exactly with the wiki just just for those who are not familiar with github wiki's they're just uh they're just a secondary git repo and we can we can pull things out of that easily and stick them into a uh documents directory in the main repo when we choose to do so yeah that that is nice and I like some of that integration between the wiki and and and the repo as well like referencing issues and prs fairly automatically and things like that becomes relatively pain-free I'm just going to take a note cool excellent thanks Frederick any other any other comments uh questions or concerns on on you know utilizing the wiki for some initial documentation as we go here okay so the next action item we had pulled out was uh was John uh you had an action item as documented here to crisply express the invisible network and via problems to the mailing list and or during the meeting this week well didn't do it I started playing the code yesterday and Frederick and Kyle helped me get started so let me do a little more of that and then after that I shall add some comments it was mainly around you know how do we integrate with service mesh oh what is our position of service mesh in that are we an invisible network or we are another network with service mesh how do we tie that together make sense do you want me to to have this AI sorry when I saw invisible network oh go ahead friend yeah sorry when I saw the English I thought it's mission learning my bad I read Emma last mission learning we're not we may be hip but we're not that hip yet prim okay and then the last one the last action oh John I think that's that sounds really good yeah and definitely as you know as we can help you um as you go along here that's totally that's totally great so we'll look forward to to that next week then okay yeah thanks and then we had uh the use case document I know I myself um have not commented or provided feedback I don't know if anyone else has this week as well Chris sent an email this morning so we had some feedback but I think it I think it really helped everybody if we I just had an email I mean even just like I don't understand this is good because then we can actually add add more content or this is not clear you know those type of comments are really helpful I think friend what do you think yep I felt Chris comments pretty useful and started editing it based on his comments so yep okay so we'll move this to the mailing list and not the machine learning algorithm for okay machine learning can solve it we should we should actually that's true to be fair if it can solve it then I think we might want to look at that yeah I will probably pull an ad for that because he made me think on those lines after a discussion about uh on demand uh on demand channels or on demand uh we had slant channels so sorry okay uh we had a little bit of background noise there if you're if you're not talking it would be excellent to to to go on mute uh excellent okay he's talking on mute oh yeah he is yeah I noticed that too yeah yeah as you were on mute oh so I'm sorry about that um no I was gonna comment um you know in response to Chris comment like I am clicking some sort of trying to communicate some other ideas I've got some preliminary stuff that is really not fully baked but it's all being done in the open so there's literally a network service mesh folder um that that all of you can read and so forth and and that's literally when I pick up a pen that's where I pick up a pen so like some of the stuff that that perem was talking about with sort of network service mesh wiring some things like that is there it's certainly not baked so so I've added that as part of the use case uh that's awesome cram sorry that's okay dude it's all good yeah excellent yeah so I suggest uh so so thanks uh John for pointing it out and Chris for starting the discussion I I haven't looked at that this morning yet on the mailing list but but yeah let's let's see what we can do on the mailing list this week with this with this discussion and see what we can wrap up and then uh you know I'd like I think we should propose if we can do that we'll we'll do another AI to wrap this up next week in the meeting because presumably we will have had a lot of discussion on the mailing list this week and we can follow up with things that aren't clear or points that people want to make or things like that that's not good to everybody yep excellent okay so we'll keep moving along in the agenda here so I thought you know we usually do a section now on review of development activity um um so I I wrote these so Frederick if you're okay I can leave this section this week I I filled all this in this morning so I'm I'm uh yeah go for it okay so at the end but yeah go for it oh yeah go ahead and add it at the end if you want in the agenda while we're going through the top part or or whatever you're you're good with so um so I thought I would welcome we had new contributors this week I thought it would be interesting to kind of put those in so critique and uh I I'm going to perhaps butcher sir gooey's name Ed do you know how to pronounce sir gooey's name did I get that right if you're if you're asking me for pronunciation help we're all doomed we're all in trouble okay so I apologize but welcome to the new contributors that had some some half the time I kept it on and write it it's a single syllable that's true so the other thing I did was I I have these I have these handy links that I'll try to put up keep updated so for example this one should if I did this right you can see the issues that were closed this week um so you can get a sense for for kind of what's being closed and then I added another one for the pull requests that were merged in the last week as well so so there is work happening we can see code in all of its glory being you know reviewed and pushed around and merged so I think that's that's pretty good so people want to get a sense for what what's being worked on um so ongoing work uh there was at this point I think we only have three pull requests open and if if anyone is working on something that's not here that you haven't done definitely feel free to add it below this and we can get to it but there was the issue last week we discussed deletion of crd so I have a patch for that thanks to uh critique and Frederick for reviewing that um I think I've addressed all of their comments except for the refactoring one which which Frederick I had proposed on that that pr that I I could push a refactoring one after this merges if you're okay with that but this this should correctly handle the deletion case for us um so that so hopefully hopefully we can get that resolved today yet but we'll see the other one I was working on was was integration tests so I have a pull request cell for that which essentially fires up a mini cube in Travis at this point and verifies that all of our sample yaml files which contain network service objects network service endpoint objects network server network service channel objects all of those can actually be created and then viewed um and and all of that works so once pr 72 merges we'll be doing some integration testing um as part of our Travis runs as well so if if people are interested it would love to get some some feedback on that one as well and then the last one was uh sir gooey pushed pr 79 this morning around uh unit test for crd validation as well and he's looking for he pinged me this morning and indicated he was looking for some feedback on the approach there as well so does anyone have any other ongoing work I know Frederick you had mentioned that there was something you wanted to discuss here so the floor is yours if you're if you would like to discuss it now or anyone else actually okay so yeah just a um a couple other things that we should start working on uh so I noticed that there's something I noticed from just working a large number of you did repose uh so when you're working in or go go project specifically uh when you're working in go one of the issues that people run into is the uh is how do you set up your initial development environment and how do you integrate with the deployment or the dependency tools properly as well so uh so we need to we need to work out a way to uh minimize some of these issues uh that we have sort of example if you put your your repo in the wrong spot in your go path or it's not in a go path and then you try running depth on it uh then you sometimes can get some weird uh stuff going on with it so in terms of how it builds how it generates code uh if you end up generating code that ends up in the wrong package or or uh or even worse you vendor your own repo and then self-endering self-endering so so which means it which is which silently works at first until you try changing an interface and then your IE says yeah there's no problem with this you check it in and it explodes and I think we do have a check that prevents self-endering from actually passing CI right now though don't we I hope so uh I I recall pointing it out uh I I think we do yeah yeah do you added something a while ago on that yeah yeah I did I did and the thing is I guess what may be a good idea is is and this is a good thing for obi-ki frankly um is the sort of ways you could hurt yourself and how to recognize when the CI is telling you that you've done them um I I do vaguely recall from putting in the self-endering stuff that there was an attempt to try and make the error messages really really self-explanatory because I I I have a personal thing against error message that says that thing happened and doesn't tell you anything else um about what to do now um right well what I was going to recommend as well is we we do two things number one is we we document as well as we can and every time I get a new user who has problems with it once they fix it then their job is to update the wiki in a way that they would have understood uh until no one's starting no one asks that question anymore the second thing is we need to add into the bill script when you do when you run the build locally just sanity check the test to see whether you're in the the correct location in the in the go-pass in order to in order to work and if not in it then it does instead of just sending out an unhelpful error message we just print nothing now we we print out a uh look we print out a path to the wiki as to where they can where they can learn how how to set up their environment I'm I'm I'm still really tempted by printing nothing just for a moment um I'll get over it but it's still um so this these are all these are all super good ideas and I have completely failed in writing some of them down in the meeting minutes and I'm going to try to do that now so that's okay I'll get I'll get them okay you got it okay thanks yeah yeah I've also just dropped a link in an example of self-documenting error in the bill this age um where basically it dies for what even if you're reading the script is probably an obscure reason um and and then it it basically says do this to fix your problem um you know it it essentially you know it it dies because of the vendering issue um and then it tells you how to fix it yeah part of uh part of my plan as well is to is to try to eliminate these kind of roadblocks that prevent people from joining in the first place so if uh if anything like this comes up uh you know definitely feel free to contribute towards it or contact contact me and I'll help come up with a uh with a way to mitigate some of these some of these issues so especially if it's around how dependencies work or go relate a tooling or anything like that like definitely definitely get all of me yeah I just want another example if you if you muck up go format which is also a deeply mysterious thing uh if you don't know what's going on it tells you exactly what to do yeah thanks to Fred for helping me because I had I had I think I had all of those problems but I uh you did you did I feel like this whole discussion was a roundabout way to give John more action items which which who knows to Frederick for for subtly getting John another AI one thing one thing I noticed was now that I have it working is I'm I'm trying to run it on GKE and the cluster roles the create permissions for the um authorization our back stuff needs to be set so I have having to go through and get that set up in our environments on mini cube I assume it's just default yes yes so is it possible so if you end up needing like a separate YAML file for GKE for with some of that role stuff I don't I don't think I need a separate separate YAML file I think you should go set the IAM rules in your GKE account ah that's what okay so that that would be another wiki thing then we could document on here cool absolutely yeah once I figure it out I'll I'll pop it in I like it but I think it's and I'm sure AWS and the zero will have the same flossing that's that's likely the case you know you know honestly like so John for this type of stuff we're running it on I may even swing to just pushing down the markdown file into the repo without a run this on on GKE for example you know rather than the wiki initially I don't know I let me get it working then I'll have I'll get that I'll capture the gcloud um CLI and then any IAM stuff I have to fuzz with so we at least have a one way of doing it I'm sure there's probably there's probably not a I mean one thing I would also really strongly commend if possible it's not always possible it is you know if basically you can get the how you know detect error how to fix error in the same place in whatever script people are running whatever you can do that that's golden because it becomes the world explodes brief message about how to make the world stop exploding yes exactly that's the best if you can do it you can't always cool yeah so um uh since we're talking about that particular space as well uh so with the minicube that was that was uh discussed earlier or I don't know be discussed there not maybe I think we just have but with with the work with the integration stuff one of the things that we need to check with minicube is is it possible to pick the the cni plugin and the the stn and inject it into into minicube and the reason the reason for this is that when people are developing they're going to want to develop against their own stn's to to test and I'm not sure if minicube has the ability to inject an stn and so which may be problematic from from a testing site you know for start you don't want to run vpp if it doesn't give you an easy way to inject vpp into it then we're going to we're going to run into problems so uh if it doesn't then there's a couple other approaches we can we can try out one of them would be to run the cube admin commands directly and we can then drop in any cni configuration that we want which would specify the stn and see if we can try to get that if we have enough privileges in in travis and i assume we do then that may be an option to to get an initial to get an initial test working with with vpp or or some other driver well i think that's actually a good point and the other thing is that you know as we get a little further into that because for development it's great it's probably the case that as you said we want to make sure that we we are open to testing across whatever sort of cni or stn people want so that when as we're doing development because the goal is to support multiple different approaches to the data plane um that we can get something that prevents us from you know from unknowingly breaking one data plane or another as we're going through this process yeah so i definitely agree as well it it appears like i because i looked at this previously i think mini mini cube does support cni so so we should be able to do it there but but having said that i agree that we definitely want to make sure that that cube adm that we can that we have some testing for that method as well and that we can we can utilize that too well to be more to be more accurate uh cni will be present in mini cube but can you change the cni driver and that's that's really the question so that's that's something that we we need to to look into and the reason for changing it is unless unless you're okay doing everything with the default driver which might be flannel or it might even be uh might even just be a linux bridge that it drops things into uh then we probably want to be able to to change it out even just for our own default so um so we we need to add that as a as an action item basically yep i just i did that there so we should open up an issue and and someone can take that and explore this and then report back on the issue if that's possible or not so yeah it's it should be a pretty easy task so um so if someone wants to to grab that otherwise we'll we'll get we'll definitely get to it but um i was thinking about at some point we may also want to in a similar vein predicate may also want to explore um you know using using a different runtime other than docker as well right yeah although that for me that's probably lower on my on my priority list but yeah that i think that that's definitely that's something good idea the main thing when it comes to that is that the network namespace is discoverable and and accessible and as long as that is then you know we should we should be good to go and it should be pointed out i did verify it's discoverable and accessible in docker because that was the that was the thing that occurred to me is being um an immediate thing that could go wrong and make all of this incredibly hard yeah and and in terms of the yeah it's easy to discover in in docker and the other thing that's that's easy to look for as well as when you spin up a pod the first thing it does is it's it spins up a dummy pod called pause pa usb and then all other containers they need to use that network that that namespace then reuse that particular pause and that allows you to have restarts without losing the uh the state or allows you to add multiple pods or multiple containers on top of that and without democratizing the uh the network because the main one so as long as we can discover that the the namespace of that pause and um then we're then we're good to go and that's that's that's not difficult to do you know even if you don't have any kubernetes access you can always do docker ps and and work it out programmatically so um but yeah i think i don't want to take too much more time on uh on the that was one of the changes we're trying to get into the device plugin because the allocate call if we return the container id you can get the namespaces without that you gotta do a bunch of futzing just known yeah yeah it's like uh you play a little regex dance it's uh it's not fun yeah it's it's doable but it's not it's not using public apis yeah so yeah if you if you see a public api hit uh hit um that gives us this information you know by by by all means like that's that's definitely let's definitely use that well i think we should lean on you know it's one of the things we need to lean on the device plugin group far we there's other people leaning on it leaning on them for it so it's not uh it's not just us but i think um having more people lean on them okay different action different action item and this actually should be an action item is that we've wasted the port for it uh publicly okay for which thing i was briefly distracted to get namespaces to get namespaces from the container we need to get container id no we don't okay how do you do it yeah so let me here's the thing i've actually gone through and i can reconstruct it given 10 minutes and started up a docker container from with it a docker container you can go fishing and proc to find out your namespace you can then get that namespace from within the docker container translated back to a name you've got to get you've got to get the docker container first you got to get the container id first right right you have to be in the container but you don't have to get the container id first yes but you're not in the container you're in the demon set no no but we get that information from whatever is sending the the connection request call to the nsm right so we don't this is part of the reason that the nsm was done this way is there's a ton of information you know there's a ton of problems that people are having that they're trying to push in various places that we literally don't have um because of the way the architecture is built so the fact that you've got someone from inside the pod making the call at the nsm saying please there's definitely information in the in the container as well and that that is an option we can we can pull information from the container itself and we can add it as part of the as part of the uh plug-in so we don't have to we don't have to rely on any special tooling or anything within the the you mean you perfectly love that information we can just encode it directly into uh into the into the service or into the network service so that's definitely that's definitely true it may be that it's a perfectly lovely and good thing that would be wonderful for the universe it's just not a thing that's in our critical path um you know and and a lot of that was intentional i spent a lot of time looking at like what you when putting the architecture together i spent a lot of time thinking about not having to go ask for changes of unknown timelines in order for it to work um and i think and of course one discovers this one codes but i think that we actually work just fine with zero changes to the system um somebody if you're going to handle physical objects that have to be returned is eventually going to have to fix the deallocate problem in the device plugin but but and that would be beneficial to us but i don't think we're by any means the most important people who care about that problem so yeah so um action item for ed then uh i'll align that path in the wiki go ahead nice one nice one vertical yeah yeah we can definitely go ahead but yeah it's definitely definitely something i thought about as a problem because otherwise you do have to go and get all kinds of new holes poked in the wall through various paths and and i know that from what i've been reading from the people who actually seem to be gatekeeping on the device plugin stuff they seem really leery to be passing what they deem unnecessary data around so yeah now that you bring it up i remember having this conversation in length with you about whether we could get the namespace uh or not and we explored different paths i did a mechanical exercise i just didn't write it down so please do write down the action item to make sure that i actually do write it down this time because i've done the exercise twice now and this is about to be the third time um so apparently the only bit i'm retaining in my head is that the solution exists yeah so the the third um i guess we need to make sure we have time for use cases as well so i'm not going to i'm not going to bring any other things up because i could do this all day so sorry for the question um so is it going to be uh like or are your your volume is pretty low can can you oh sorry uh am i audible now yeah that's good okay uh so question is about the sdn controller on the you're planning to get it in which sdn controller you're planning to start with so so there's a couple there there's there's two areas on this number one is what do we what do we test against and the second one is how do we set it up so that people can test against the sdns that they uh that that they want to test against and specifically we want to make sure in the long run that we have a set of integration tests that people can can run to tell whether or not their sdm um works or works or not and of course with some don't have to be some options because like suppose you have a sdn that doesn't support uh vxlam for some reason and of course that test path doesn't make sense but an auto auto negotiation that ablates that uh would so so but um yeah i think i think right now uh because of the the makeup of the of the team i think that getting a vpp in the path just for the initial set of testing is probably going to be uh is probably going to be the best but i want to be a bit careful with this because uh one of the there's a there's an important part on on optics and my i've drilled this into add over and over again uh is that we want to be careful not to be seen as like this is a dpp sub project or legato sub project it's a project that uses legato it's a project that has support for vpp but is not part of those projects and is trying to be part of a bigger part of a bigger ecosystem so um so part of so part of that is is ensuring that we have a path to enable those uh those use cases and to enable people who want to bring their sdns to too easily too easily joining it the system i am emphatically in agreement here and and basically it is really crucially important to have support for multiple ways of doing the data plan data plane and the sooner we get to that that multiple path support the more confident we will be in the fact that we actually do that successfully right um my experience has been when you have a system where you're supposed to be able to plug in um different implementations of a thing until you get that second implementation you don't really know whether you've done that right or not um yeah and i i think we have because of the people that we have ed having very strong influence over the vpp and the and the make those who are to where i'm the tsc chair at fido among many other things so i am personally very close to the vpp community um but i also understand that for open source projects to be successful you can't go welding shit to shit right you've got to actually truly be open right and in fact ed uh i'm in this project mainly because of vpp so i see this i mean yeah i mean yeah it's all okay for people to be vtc thanks so well so one sorry sorry to digress uh question is uh um question is my assumption that the nsm itself would have uh would have the intelligence or the control plane part in this in this journey and probably sdn would just uh argument it with additional information is that right i tend to see the nsm as the the local control plane um basically it's not like the great control plane in the sky because i think that as a matter of personal technical opinion and people are absolutely allowed to disagree with me that you have to be very cautious with great brains in the sky because they often scale poorly and so i tend to think of the nsm as the local control plane running on each node which is not to say we won't discover something where we need a great brain in the sky as we go along i just haven't thought of anything yet where we need one beyond sort of the store crd's and kubernetes thing okay yeah so i think yeah so so real real short on that vpb i think is a is a good path but ultimately my what i what i see it's trying to do is it's it is trying to aggregate some information about about its domain but ultimately it needs to pass that information uh it needs to pass enough information up to uh to the sdn in order for the sdn to do it's just work as well you can think of it as like you know like how uh processors have co-processors maybe we can think of this like a co-control plane or something similar to that that gives you this capability i i think i think quite honestly the way i've been thinking about it please notice not the only way to think about it is as we're building out the nsm you know we're building it out as a series of plugins and effectively the you know we there will come a point where there is the the plugin that talks to the data plane and whether that plugin is talking to the data plane directly we're talking to some nsm that's some sdn that's talking to the data plane um you know i i think we need to be able to support multiple plugins that talk to the data plane um and and we need to be pretty agnostic as to whether we're just locally manipulating a data plane or asking some sdn to do it for us i'm gonna point out that we have about 17 minutes left on the meeting yeah yeah i was gonna say this has definitely been a really good discussion and i think everyone's i think these are all really good good points we do have a few items left so should we should we continue with the agenda at this point so one thing i did want to make sure um since especially since we're dropping it off the meeting today i would like to make sure that we we touch on the meeting time planning thing yeah we wouldn't do there that's that's what i was thinking we would jump to that next before getting into these other things um yeah so so prem did you you you had mentioned this earlier in the meeting would you like to talk about the meeting time planning yes uh so i just created a simple google poll uh i just sent it to ed to see if i need to add something um so just three simple questions one is the time zone from where the participant is dialing second thing is whether they're open for alternating alternating the calls meaning between mornings and evenings and the third one is basically a picked up a few time slots based on the previous history so i'm going to send out that poll once uh and our head provides the feedback yeah i did want to actually check in with one of the things like you were going to try and find people who concretely have the problem with the current time slot yes i've tried i know he asked me i i did try crowding a colleague who um if you haven't heard from him i guess he hasn't picked up interest i don't think so because i mean one of the other options we may want to add to the poll is so this whole conversation started because mike brought up the the issue quite rightly um that friday is a weekend for some people right and we all know that international scheduling of all kinds is complicated and problematic um and so prem being you know being prem stepped up immediately to volunteer to do a poll that didn't have friday on it and and so one of the things we do have to decide as a community is um is this time slot working for us and do we want to move it um off of its current time slot um you know that that's something we need to talk about i don't think we have anyone concretely right now who has a problem um but you know if we you know we do need to decide we'll go to do that uh right just friday's work yeah that's exactly right in fact one of the options has to be to keep things as they are we don't want to change something just for the sake of changing it yeah but simultaneously we may be missing out on people who are not here right now because the time is not good and they're they're not here to voice their their opinions and so absolutely absolutely and i'm definitely you know we definitely need to make that happen but but but on the other hand as you know i i and i will i am like for example we've been talking about this for four weeks and i know mike's been trying to get someone who says they want to come but can't come if after four weeks of trying to get that person to indicate to somebody like when they can attend and everything and we don't hear anything at some point we just move on yeah cause right we have to have keep it the same as an option yeah yeah i'm i don't know if i'm keeping it the same as an option just um yeah just we we should make sure that uh we have a venue that people who are not here can you can see it which should be the mailing list i hope yes yes that's that's fine go ahead and send it as far as i'm concerned that's that's fine yeah so i i think the the one the way you put it together for i'm did not have keeping things the same as an option but i'm asking you to do it cool yeah in fact what i'm going to do is i'm going to start the poll with do you want to keep the meeting same if no then i'm going to provide them the options cool excellent okay add few updates to the use case document i can probably wait until we incorporate or we listen we listen for the review comments and then we can have it uh incorporated and we can have a final review should we do that so so basically will because we have the previous ai to have everybody continue the discussion on the mailing list so then next week we'll we'll do another you know it might make sense actually prem next week to try to focus maybe you know half the meeting towards the use case document again assuming we have a pretty lively discussion this week how do you think um yes makes sense uh makes sense um also depends on the number of comments i got i uh did see comments from this uh we also got some comments during the meeting from daniel brunner at bell canada which is also and some of those comments i think are really good and some of the comments either i misunderstand what's going on in the use case doc or he must understand what's going on in the use case doc i'm not sure which um because some of them he's like we need to be it's important that we can do xyz and i'm looking at the going i thought we could oh i'm so confused so that'll be good so that's good so i mean we need to clarify so that's yeah that's clear we are doing and not doing yeah just a minute update on what i've updated on this case doc is that i've just added the distributed bridge um and then i've given options on it one is basically a full mesh which is persistent and other one is basically on demand yeah that's a quick update cool okay so ed i just copied this this conceptual review section from the previous week i don't know what what you want to do here with uh i you know the this section is all this this set this has always been about um sort of of you know it's just the whole idea with no resurface mesh it's very cool but it's a little bit different than than folks have looked at this stuff in the past and it was just to provide some space for people to sort of talk through the concept it feels like people are getting good traction on the concept um and so i'm okay with that's probably because i haven't been here the last two weeks i do want to point out though mike um and i i didn't you know call you out among other people when i was pressing appreciation at the um network service mesh meeting that presentation sorry the the uh signature meeting that presentation would not have been nearly as clear if you had not been uh insistive on precise expression of the idea so i do appreciate that um um yeah so um i think maybe the i don't and maybe if you and i could just get some more time i'm not sure we need to take everybody's time no i am not related to do that because i've been finding it very valuable um but i suspect that it's valuable for you and it's valuable for me but it may not so much be valuable for an audience yeah so let's just find some time to talk directly cool that makes sense so i guess unless anyone has anything else we may you know give everyone i have a few questions um that's what the structure is for so the question is assuming that the NSM is going to be the uh local control plane or the SDN or whatever it is um i just want to start a discussion around how do we get the uh relation between the bgp routes to that of uh how the mesh has to be created things around that right right so so i think what you're saying is you have something that that is speaking bgp that is is essentially you you have some SDN that's interacting with bgp and how do we actually interact correctly um and my off the cuff is um that whatever data plane plugin for nsm you had would be the thing that would be causing that to happen so you know let's just take a for instance right and i please note this may or may not make even even make any sense you know let's say that whatever you're doing involves locally manipulate you know you want to do this in a way that involves locally manipulated data plane and advertising a bunch of routes to bgp right and so you build an nsm plugin that locally manipulates the data plane and advertises a bunch of routes to bgp that's awesome but i don't think nsm the common nsm thing that's that's across every nsm i don't think that necessarily is something that should interact with bgp itself does that make sense okay uh okay uh the reason i i brought in that particular discussion is uh what in case if uh the whole mesh uh gets created based on the requirement of what are the routes you need to expose or what are the routes you need to support would would would that be a requirement uh when we plug into such bgp speakers oh so are you asking basically what routes get injected into pods and how right no okay so sorry let me put it in simple terms okay that's a that's an interesting question but not the one i thought you'd asked yeah so to put it in simple terms what i'm trying to say here is uh assuming that you start on a clean slate uh with uh with the service mesh right with the network service mesh what you're trying to do is you're trying to create um the the uh vxlan channels between the uh pods and then once that is done basically the channels gets exposed um and how is it happening is basically based a bit of the pods requirement as well as what is the requirement from the external connectivity right um now uh when we bring in the external connectivity uh what is important is one is uh the pods requirement asus meaning or the application requirement asus but there is also a requirement that is coming from the external world on what has to be exposed uh and what should not be exposed right um that might be driven by policy but when we talk about policies related to that of network what matters is matters relates to what which of the pods have to be exposed to external nodes and which of the pods should not be exposed right um so here a bit of intelligence on how the a bit of intelligence on the policies uh particularly the network policies would essentially help in creating the whole mesh so that's what exactly i uh mentioned here and i use bgp just as a reference okay so in my mind there's sort of two things that are going on here um and there are two places that you might have what you might think of routing in this in the the system um one thing one place you may have it is inside the pod um it may by virtue of having gotten a connection to a network service it may need to have some routes to selectively send some of its traffic to that network service so a really simple example of this is imagine the network service i've been connected to is a um is basically secure internet connectivity right so it's something that lets me connect securely to my internet for whatever the definition of secure is right um and so it may be that when i get that connection i should also be receiving a set of routes that say okay here are the prefixes you should be sending out uh to the network service that is from the pod the network service that is secure internet connectivity um right that's sort of what i'm calling the inside the pod routing and in i've been thinking of that as something that comes back um via the um you know connection accept uh message so you know the far end the network service endpoint accepts the connection it understands what addressing it would like people to have when it talks to them what kind of traffic should be sent to it etc and that comes back to the to the nsm which can set that stuff to the pod um that's kind of how i've been thinking about that right now now then there's the secondary thing that you mentioned and that is literally if i have a pod that is trying to connect to a network service and i have a bunch of different network service endpoints that could provide at that service how do i decide which one to connect it to right and that's that's what i think of a sort of the um policy the sort of connection policy stuff i've been repetitively calling it uh you know network service wiring and thinking of it as analogous to istio's virtual service or route rules concept right um but i think we look at those two things then you can start asking yourself sort of like how do you connect those to other systems does that make sense to everybody i think broadly i'm following what you're saying oh good yes hey okay cool um so i think that's what i want to have okay thank you yeah one just just to inject something real quick one thing that we're probably going to have to build out um is we're probably gonna have to add something for that that uh turn some of these into a into a shared library that sdms can can pull in so for example if when you talk about how do you add a route you know well in order to add a route you have to spin up a container that container has to have net admin that has to run the correct net link commands or uh or otherwise whatever whatever other uh api calls against the kernel in order to set properly and this this would be a really good area to have a single location or set of utilities that can that can do this on behalf of uh not to say it's the only right way to do it the way i had been thinking about this was not actually to have the sdms do that um the way i'm thinking about the network service mesh likely or yeah the way i've been thinking about that was the nsm the the nsm is the one that operates on the stuff that goes into the pod based upon the response that it got um from you know the things that it's interacting with right so if it if it you know gets back and the nsm understands from its pure nsm on the other end for example that you know these are the things that should be passed back and i was seeing that coming through the accept connection and i actually have a picture for this that might help one second yeah and it could be the nsm as well it could be some maybe some set of labels or or other information that gets tagged in that um that says please inject us on my behalf and that's that's fine as well we we just have to have a mechanism that uh that performs this because you know like the use case that prem gave where you have vgp uh you have a new route that you need to support but there's no easy way for uh for a nsm-based library or demon running within the container uh to inject to inject in unless unless you have a side car and i think we we're we're looking at eventually putting in the side car that would have net admin and then we could do it through there yeah i mean one of the things that occurs to me there is that um so when i think about this you know the all this stuff so let's go back to the vpn example not because it's the only example but it's it's it's sort of um it's instructive right so if i'm acting to connect to a secure internet connectivity service and that ends up giving me a connection to some vpn gateway pod somewhere else then it is the case that i would expect to be getting my route updates not from an sdn but from that vpn gateway pod because it's the one that actually knows um my sdn may or may not know um you know unless it happens to be intimate with the vpn gateway pod and so i i think though what you did call out is the need to be able to dynamically update some of that information um from the the far end of the connection to the the originator of the connection over time does that make sense yeah that's that's what i'm trying to to point out like i actually don't care where the information comes from as long as we provide a an easy way for people to perform these operations that uh that that we can expose and we just make it very very easy to to inject these things in and we can we need to work out how we want to expose them and how much control do we want to maintain or versus how much we want to to allow them to be explicitly called but ultimately i think that that's that's what we need is we need to have some like i i want to avoid getting different implementations to inject their own in their own paths and if we can get it to be coordinated through the nsm we'll be in a better we'll be in a better place yeah and that that was kind of how i've been thinking about the problem doesn't mean it's the only answer but the coordinating through the nsm was definitely how i've been thinking about the problem um cool so we're at the top of the hour i do want to be respectful of folks time i do appreciate all of you uh coming uh and all the folks who are starting to participate in push code that's awesome and i will see you all next week yep sounds good everyone bye bye they're