 Good morning everyone. Good morning. I realize it is not morning for everyone. So quick reminder to everyone, especially new folks on the call. This call is recorded from the time it starts and then when it ends it is automatically uploaded to YouTube. So do realize that you are being recorded and what you say here will be public. Yep. Cool. That said, here's the link to the meeting minutes and if folks can start adding themselves to the meeting minutes that would be useful. Sorry. Now that the race is on and then usually it takes a few minutes for everyone to form up and we'll get going then. By the way, do feel free if you have things you want to add to the agenda. We usually start the meeting with agenda bashing. We haven't formally started that yet but you could go ahead and add things to the agenda anyway. We're pretty free flowing about the agenda. For folks who are just arriving, we usually allow a few minutes for folks to turn up. It usually takes until about five after. Also, please keep in mind that the meeting is recorded from the time that it starts and is automatically posted to YouTube afterwards. Everything you say is being recorded and will be public. If folks could please go to the meeting minutes that I just stuck in the chat. Sorry, anyone? I stuck them in the chat wrong. That I just stuck in the chat. We keep a list of attendees. This is actually super useful. So if you could add yourself to the attendee list, that would be great. Can I get a mic check? I hear you. Fantastic. Let me go ahead and actually start sharing the meeting minutes. That typically makes things easier for folks. Can everyone see the meeting minutes? Yes. Awesome. Also, we need some additional things on the agenda. So we have to talk more about various things other than where we're going to stick the repo. Yeah. Do you want to talk at all about some of the SDK stuff today, Nikolai, or are you still sort of ruminating? Yeah, I can. Awesome. I think we're all just, many of us are just getting back from the Christmas break. Do we have Matthew on the phone? I know he also wanted to talk about moving the Vagrant to using Debian 9 instead of Ubuntu 1804 because apparently there's a problem with using the Ubuntu 1804 boxes with Libvert. Actually, his latest update is about Ubuntu 16.04. Oh, okay. So you're just trying 16.04, not 1804? Yeah. Not the Ubuntu 1804, but the generic 16.04. This is due to DNS mask. I don't remember something about that. Yeah. I mean, one of the nice things we want to look at is, frankly, this is another option we can take, which is that you can specify the box conditional on the provider. So that basically, if your provider is Libvert, then you use whatever. And that actually makes us quite a bit stronger because the broader set of environments that people are working in, with that work surface mesh, the less likely we are to have something that works in one environment and not another. I was looking at this the other week. I mean, I did some code changes, but I haven't pushed anything because it was basically hypothetical and I've never got too far as testing it. Well, it's now an 1804 box because I got frustrated and I upgraded it. And I was trying to get Libvert to work. But another option rather than using Vagrant is actually to use Terraform directly against Libvert, which is probably the better approach, to be perfectly honest. But it does mean that you're not using a box. You need an image rather than a Vagrant box. But the problem with Vagrant boxes is they're always tied to a provider. So that actually works better in some regards. Really kind of comes down to the make machinery was designs that you could have different ways of approaching the problem. So there's nothing wrong with having an MK file that will let you do a Terraform with Libvert directly. Yeah, it ended up with another layer of indirection, which as we know, solves all problems. But it was, we have, I'm going to blame Frederick here because his footprints were all over it. The make files are a bit funky because they're not really make files. They're just glorified script files in the form of a make file. But they're nested in such a way that if you change out the provider, you just basically change, it loads the different more users, a different set of make targets. But if you use that same trigger a level deeper, then you can basically make use Terraform against different make targets. And that also works. And I got it certainly partway. I can't say I'm proud of that particular piece of work yet, but the theory works. You just use Terraform to, I think what I was doing was using Terraform to create the virtual machines as well as get them configured. And that was making steady progress. And it also theoretically means, I think the long term aim that would be a good one is to use Terraform consistently for everything rather than doing Vagrant one way and other things a different way. But it gave some possibilities. Sorry, very, very woolly, I know. But I'm trying to work out how best to put that code up somewhere where someone can have a look at it. Well, before we dive down too much into this, we can stick that into the agenda as well. Yeah, we can. But seriously, it was like three weeks ago when I did this and I can't remember what the hell I did. So the actual answer here is for me to stick that on GitHub with no promise that it works. So at least somebody can see whether or not I'm doing the right thing or whether or not there might be a better approach there. Yeah, I think we should probably put this further down the agenda. Yeah, let's do that. But I also don't want to make the perfect enemy of the good. Well, at the moment, the virtual box is my enemy because I can't run it on the decent server that I have. So it limits what I can do. But that's why I was doing this, because it was, you know, if you want to, if you want to get this thing working first, you have to shave a yak. That was where I got to, to use a Perlism. Are you sure you don't have to flex a yak? Well, if you think if you wax it, that would probably be easier. But that's not how the how the saying goes. Also, you don't want an angry yak. And we should put that on the agenda later as well, or this could get into a very long discussion. Cool. So we're going to get the meeting started. So welcome to the first, welcome to the first meeting of the new year. So if you are new to the call, please add yourself to the agenda. And let's make sure the agenda is posted on the chat. But it looks like it already is. So we'll get a message. And so I'll go ahead and stick it there again. The chat only shows up if you're here, when the chat message is sent. So if we got people who joined last time, I put it there. Now you have it again. Great. And so agenda bashing, if there is something that you would like to talk about, please add it to the or please speak up now so we can add it to the agenda. Don't be shy of something that occurs to you as we go. Yeah, absolutely. And okay, so events. So we have Bozdem. I see Taylor just added something on the chat. Is that something to add to the agenda? No, it was just about the Libvert with Terraform, which is pretty cool. Okay, cool. So let's make sure that gets added as a link on the bottom. Okay, so we have events. We have Bozdem Brussels coming up with a networking dev room in February, second through the third. Nikolai added a relevant talk, which he is going to include network service mission. Yeah, but that was actually not accepted. And yeah, I'm not traveling, unfortunately. Okay, so is anyone going to Bozdem then by any chance? Or shall we remove it? Okay, let's go ahead and remove that. So we have upcoming events coming up. KubeCon EU, the call for paper closes on January 18th, and that is going to be held in Barcelona from May 20th through 23rd. We also have Mobile World Congress coming up, which is in February 25 through 28. So if you're involved with Mobile World Congress and have a way of getting network service mesh involved with some of the things you're doing, definitely feel free to ask for any help or anything like that. We'll do as much as we can. We also have the ONS North America call for paper, which is going to close on January 21st. And that's going to be held in San Jose from April 3rd through April 5th. So which is definitely going to have attendees because Frederick and I are both in the area soon. Absolutely. And so let's... More importantly, the bar of the San Jose Convention Center is a good place for us to hold it as a happy hour. And it has reasonable selection of beer as well, which is another step in the right direction. And if we don't like the bar there, I think it's in downtown San Jose. And if it is, then there's a lot of things around it. Okay. So for... I have a question for Barcelona actually. So is anyone planning to apply there for paper? Because we actually don't have much time today. So we have 10 days. Yeah. So for the QKaniU, I think we want to get a broad set of people submitting talks on service mesh and on different network service mesh topics. So it's for people to submit talks. You know, I've got a couple of ideas on the batting around with Frederick. Do you want to talk about any of those here, Frederick? So are you referring to the thing that I've been building so far? Yeah. I mean, you know, whatever you'd like to do there is fine. Cool. Yeah. So one of the things that I have been taking a look at is how can we take a look at something like Envoy and see if we can chain Envoy in as a network service. And so this has a variety of very powerful integrations that we can do, which may help with multicloud or multi-cluster use cases, and also potentially may also solve an issue that they currently have with Envoy and Istio at the moment, which is that you need to have a privileged NIC container start up and IP tables mangling, which may provide an opportunity for a security hole that ends up waiting to apply to the table, because it doesn't happen immediately. So there's an opportunity there that we have. And there's also some interesting use cases like what happens if your Envoy dies or what happens if you decide to upgrade. So there's a lot of really nice features that we could add into that space. So I'm primarily working on how to get that integrated in to network service mesh, and it will likely turn into a talk at CubeCon, and I'm still making a decision on whether that'll be an overnesting as well. So Frederick, there's some work done in the Istio community to replace the NIT container with a CNI driver. Sorry, I'm pulling faces, but that sounds like that's actually a step down, rather than a step up. In order to use Envoy, first you have to change your platform, that's not the problem. Yeah, it's actually kind of clean. It's a CNI plugin. It was done by Tim Swanson in Boxborough. Okay, remind me to tell Tim off next time I see him. But actually, to be fair, that's useful information, because if it was done by Tim, you know, he's a Cisco guy, I can go talk to him. We can find out what he's thinking, and maybe there are other options there, because he probably doesn't know what we're up to. I point them to you guys too. So anyway, it's the same zip code that people are trying to solve the problem, Fred. So it's worthwhile solving. Well, can you add the name of the person who's doing what they're doing? Yeah, I'll say some links in the chat. Let me dig in. The way I'm looking at this is it's not about trying to compete with them. There may actually be an integration point where the techniques that they're using and the technique that we're using with our problems combined. He will almost certainly have a better understanding of the problem than we do. Well, John knows what he's talking about, but I don't. And Tim's basically at the cold face, he's working on the stuff, so he probably understands these things better still. So regardless of whether he has any inclination to change his approach, it would be nice if we understood the problem in its full detail, which he's almost certainly happy to explain to us. So there's the GitHub repository for HGF-CNI in the chat window. Cool. So in a nutshell, I'm actually looking at how to potentially integrate it using CNI as well just to make it easy. So there really could be some good crossover there. So I also saw we had something in the chat from Jeffrey about something in PLS-STN NFE. You want to ask about that real quick, Jeffrey? Sorry, double muted. I was just curious. And unfortunately, it overlaps with O&S, but I went to Paris last year. And to be honest, the NFE, in PLS-STN World of Congress is probably one of the best conventions I've ever been to. They had a lot of really, really smart people from AMIA in the U.S. there. And I was just kind of curious if NSM is going to start trying to push into that. I mean, it's very SDN and NFE focused. So I feel like NSM is probably a good fit for that conference. So the question is, would you be interested in submitting a talk? I'd have to do a lot of homework first. I don't want to go there and look like a goober in front of the entire world and put NSM back. So I could talk to you offline, Ed, about potentially doing that, but I would have to do quite a lot of homework. I've just started standing this stuff up in my lab with another homegrown Kubernetes project that we're building in-house trying to make them work together. So what week is that, to ask a silly question? Second week of April? One second, let me put my calendar. Okay. Because the last time I remember being in, I didn't go to it, I was near it at the time that it was on and it was, I think, February or something. So I was a little wonky with that. It's the second week of April, like the second Monday. Yeah, that's certainly a good idea though, because, and I guess it did not need to be too much of a spot. Two things are sort of behind my gentleness there. The first is it's very good to have people who are actually trying to use the soft talking about it. And the second is it's good to broaden the base people who are giving talks about network service. For that audience, particularly, but this is probably true of ONS. It's nice to talk about the technologies and how we put it together, but it's far more useful to show it doing things that are useful. In that regard, we should probably work out what would be a useful demonstration for that kind of audience. Exactly, I mean, that's probably a very useful thing to sort of... Yeah, with it being, obviously, MPLS being one of the big categories that it covers, it's very geared towards service providers like Charter and Georgetown Commendem. I see a lot of my SP peers there. Like you said, it's probably the best conference I've ever been to, no offense to the Cisco lifecraft. It's all good. It's all good. Cool. Awesome. Anybody else had other events? They think we should probably try and have some presents? So there's also the container world that happens every year in Santa Clara Convention Center. It's well attended and probably that would also be... In fact, I got an invite this year. Last year, I've given a presentation around cloud-network architecture for telco. Probably we can present about networks of mismatch this year. Awesome. Could you add it to the agenda and the... Yes, I'll do that. Yeah. And then, if you've spoken there before, would you be interested in speaking there about the mismatch? Sure. Yeah, definitely. Cool. Again, if we're putting this list together and it's going in the notes, then what appeals to the audience would be really, really useful information? That I think is, again, we know with KubeCon, then talking about Istio would be a fantastic thing. We know that ONS, if we start talking service provider, that would definitely kind of start whatever the phrase is. Tweaking the nipples, probably not good phrase, but that kind of thing. Do we want to propose both birds of feather session for KubeCon? Yeah, I think so. Yeah. And that's probably a very good idea and possibly a bit more organized than what we did in KubeCon North America, which was less organized than I had intended. Not just a boss, I think, but a social session would help because, you know, we got a large crowd in the boss, a small crowd followed us out, and a smaller crowd sat down to chat about it in a bar afterwards. But the last part of that is probably the most useful in the sense that we get more people involved and invested, and that's really what we could do with. So if we actually set this up with a social session, if we can find a way not to conflict with all the other events, then that would be, even if it's lunch, you know, something like that. This time, Ian, try to keep it napkin. It wasn't a napkin, it was Heather's note pad, and I'm sure she still has it. Awesome. Right, so this is all good feedback. And one of the things that we need to make sure that we add in on this is due dates for call for papers. And I think the closest one, did we say Mobile World Congress still has an open date? I'm not sure Mobile World Congress has much of a papery sort of conference, not what I've been, but I think it's more the sort of thing where demonstrations on vendor stands is probably what we'd be able to get. Okay, that makes sense. But I think the closest one is KubeCon, isn't it? I know there's a set of deadlines on January the 14th or 10th. It's one coming almost imminently that we need to keep an eye on. Yeah, January the 18th or for KubeCon you. There was another one as well. Somebody from the marketing organization mailed me. Let me just see what I can find out. Well, if you find any additional information, can you add it to the upcoming events section? I'm going to continue on with the agenda. We'll do. We'll do. Keep going. Cool, thank you. So the main topic that I want to start with is about the repo location. So right now the repo is stored within Legato, and Legato has been absolutely fantastic and very gracious with letting us use their space to get started. But as we look at our direction moving forward, there's a couple things coming up where keeping it in Legato may not be the best choice. So the first one is it is an independent project. It's not part of Legato, which may cause some issues when we start to approach groups like CNCF to become a member. And simultaneously there's been discussions about splitting up the repo into multiple repos and having basically flooding the Legato namespace is not good form. So I own the Network Service Mesh group in GitHub. And so my recommendation is that we move the Network Service Mesh repo to the Network Service Mesh group and add all the appropriate credentials and so on. The main thing we'll have to look at in this particular path is going to be the CircleCI integration and make sure that all our webbooks work and so on. And besides that it should be a relatively straightforward move. So anyways, we'll leave the topic open so for comments or questions right now. Well, okay. I'm definitely positive about this. I mean like it sounds like it makes sense. I don't know if we need to vote or what would be the procedure to decide if we want to move there or stay here with Legato. For these kinds of decisions typically I think the best first step is to express their opinions. Often when people express opinions you'll get a sense of consensus. If there's some disagreement we might fall back to voting. But I tend to prefer consensus as a way of sort of sorting out these questions. And then the next thing is to sort of ask okay well what would be involved. Right. So I'd be curious in hearing a broader set of thoughts and opinions from folks on the notion of doing this. And I know you've also given some thought on Nicolai to how we might divide into multiple variables. So we may want to talk about what that might look like. Yeah, but I mean we already have at least the main repo on the site so at least two repos can end up in that new group. Oh no, absolutely. Plus eventually if you want to split the main repo into examples and core SDK whatever we define there. Yeah, so you already know my opinion considering I brought it up. Yeah, do other folks have thoughts or opinions on the subject? Stages. I mean granted that we want to move this out of Legato but you know let's do that first because that seems to be least contentious and then figure out the splitting afterwards. Yeah, I completely agree and I think that's step one is move we'll start with the simplest repo. We'll start with Legato site get the website working again then we'll move the network service mesh get the CI working you know make sure that everything is is working and that makes make sure the community is not having any problems committing to it or doing pull requests and so on. And then we and then we step forward and I think we also need to have some documentation up on the page as to how to how to how to update your get repo to point to the new actually it should do forwarding automatically but it's probably some good idea to point to the network service mesh repo directly. It's trivial to explain how to do a get remote update so you know it's a one line command so as long as we put the documentation there we should be good. My suggestion would be to embrace the healing power van. Yeah we could even turn it into a script run the script it fixes your repo. You can't do that 100% reliably forget repose but yeah I mean we can do something to make it as trivial as possible. 99% of people unless they're doing something really funky are not going to have a difficulty. So it sounds like there's it sounds like there is consensus towards this is there anyone who thinks it's not a not a good idea that's a good idea so the the comment was that it looks like the nsm user is is inactive and it could ask github if they're willing to to force a relinquishing of the nsm and to give it to us. We can reach out to them as well that is a that is a possibility and one other comment oh no other comment. Okay so in in that particular scenario yeah let's let's go and start putting together some uh let's start let's start putting together some uh information on this. Well I'll reach out to github today and I'll I'll ask them about the nsm thing borrowing any uh if they say no then like I said like I said I think we should move the legato site first and we may need we may need to ask uh actually Ed who owns that is is the uh I forget the name of was it netlify uh who owns the account that uh that does the my guess is that because kyle set up the netlify account that he's the one who owns the credentials for the netlify account um I believe if memory serves that I currently own the domain name um so I will reach out to kyle and see what we can do about getting credentials the netlify account but worst case scenario um we just create a new netlify account um and share the credentials a little bit more appropriately that from there um and move the domain over to it. Okay so I think we got some initial actions to uh to make this happen then. Um is there any other comments before we before we move on? Polk in that scenario um Nikolai you have an option on or you have a space for go SDK? Yeah okay so uh sometime before uh kubicon North America like in the beginning of December I started uh trying to extract the common code from all the examples that we have and try to put it in a kind of an SDK. Actually I didn't know that it's an SDK uh until Ed told me that it is um uh yeah uh so uh I have a PR there I put some work there Ed already reviewed it thank you uh I will try to uh to adhere to his comments of course for the time being it was mostly about just extracting the common parts there's no real big uh crazy design please don't ever adhere to my commands if you want to think about my suggestions that's great but but you know everything yeah yeah I mean I will try to to do as close as possible to whatever you're proposing I mean I'm still trying to evaluate how how it could look like I already changed some namings there uh and refactor it a little bit but yeah I mean the idea is that we end up with a easy way to create services in go okay not only services network services and then points but also clients and uh this should be really trivial so whatever threat was showing on the stage at kubcom also on the vpp conference there should be really trivial I mean it should be really easy to do it after the SDK uh gets uh gets merged um I strongly suggest and would use any comments so if if anyone can anyone interested please just see the PR it's a 604 the pull request I probably need to change his naming because it's not it's not really great but uh uh if you don't want to go into details you can at least see the how the examples look like today and maybe you can have a better idea of what what uh what it's what's in the queue about it now and if you have uh and better ideas just share their comment suggest uh if um the um I love a look at it um but I'm prejudging here so I'm going to apologize if you haven't put documentation in there for everything you'd like to document of course and at least make sure there's some placeholder documents just read me's or in you know installs or how to use documents they don't have to contain anything but if they're there then at least everybody's clear that they're missing if they're not there people don't notice that until too late um and then anyone can come along and kind of help document what you're doing afterwards you don't need to get it in in the first round yeah thanks yes I I had this this in mind I was looking at some options how how we can put at least most of the documentation within the code because that's what would make sense for an SDK um I'm not sure if if I can get the documentation on go docs before I get this merge so it's a bit I don't know but placeholders as I say it's most it's not so important that you write the documentation it's more important that you point out what's missing so that the next person who comes along to edit the files can knows what they need to add um if you don't stick any sort of clues that there's missing documentation there then anyone who's doing a bit code editing won't won't add things so so all I'm saying is um leave leave space for it you know make it obvious that it's missing good good thank you thank you so that's that's about the the the SDK uh next topic is still again from me so I will I will continue so it's a call for unit tests so I started doing something there it merged my selector unit tests yesterday I will try to add more I think that we need this and actually my idea was to to to to propose to focus our main efforts there for a week two or even a month and not kind of focus on new things before we get some at least some unit test coverage because if you run make test today you will see that it's uh kind of not really existing I mean there are just a few of them um but yeah the more we get the better I see that in the new prs that we get there are already unit tests I mean they come with unit tests that's great thank you guys from Exort for for for doing this and to think that this is this is the way to go oh that's it if anyone has any comments yeah more unit tests are definitely good um and it's also for folks who are looking to get involved um basically writing testing writing documentation are always good sort of first efforts as you're getting involved uh you learn a hell of a lot about a system when you sit down to try and write some unit tests for pieces of it because you're the first step when writing unit tests is okay what actually is supposed to be happening here um so yeah yeah sorry I just noticed that there is a open issue um it's about trying to do some documentations for the ICMP examples for Kazama newcomer so it'll be really really looking forward for those kind of documentations to try to get some hands-on any examples so that I can try to follow up and to catch up the rhythm yeah this this one specifically is a bit tricky because if we manage to introduce the SDK and I suggest that you look at this PR that we that we have about the the SDK this will change the way that these examples are written the the approach yes oh really all right and that's the idea actually to make it much much much easier and to not you know need to know all the details of setting up the connections and etc etc just you know implement an interface and you're in the game yeah thanks so much yep this help we're a bit better you had hopefully get to a place where most of your work is taking some cookie cutter components off the shelf and yeah having some config in them and away you go um that would be you know even better and I know that's kind of the direction that you're going which is okay here's the cookie cutter component for ACLs okay shoves and config in that you know and plug it in like this so yeah I knew I'm gonna take it a step further as well if you're a cnf provider then having something as well on the other side where you can you can effectively uh like if you're cnf only works with kernel interfaces then and you specify that as a config then that's what you get or if you support uh mem i f or you support to be host user or so on like all of this all of these preliminary things to set up the initial connection and shared memory and all that kind of stuff having something that deals with all that so you can just focus purely on your on your logic I think it's going to be very powerful so that's we're trying to make we're trying to make that as easy as as easy as possible um okay so the next one I'm not entirely sure what the problem was so can somebody give a description of what the problem was so that we can talk about why people were talking about Ubuntu with bento or without bento or debian or you know yeah so um we were briefly discussing the details with matthew on on the trap today um essentially he says 1804 uses system d resolver which seems incompatible with dns mask then dns is broken inside the guest on dc2 by live world provider that's what he says let's back up ever so slightly um which is matthew wants something that lots of other people want he would like to be livered with the existing bagrid pieces right so he submitted a patch 577 trying to get bigger working with livered um in the course of this there's been sort of a lot of back and forth trying to make this work and not break other things so for example one of the things he discovered was that to make this work he needed to use sshfs uh sshfs doesn't work with the vmware provider for vagrant um so there was a lot of sort of dancing around these things he got all this working with a debian nine box and then I sort of suggested could we make this work with 1804 box he was sort of poking around that um you know and I think probably for the immediate set of needs which is trying to prevent matthew from having to rebase this stupid patch every time he moves um we can probably just make the box choice dependent on the provider um and that will probably work now there's a broader conversation here about what a smarter medium to longer term plan would be which I think gets into the set of stuff that um was sort of that Ian was chatting about against around terraform and bloody bloody blah and I think that's all a good idea I think doing that to the exclusion of solving matthew's immediate problem would be an example of letting the perfect um you know the the perfect proud out the good because I think we can probably solve matthew's immediate problem fairly quickly um and get that piece unlocked but I think it would also be good to look at um ways to and terraform maybe the way to do it to go and try and do this much more broadly um particularly since we'd like to be able to run across a broader set of providers um routinely so I I know for example I'd like working on GCE and AWS and other places yeah so I mean when I was looking at this then there are certain things that vagrants quite good at including making sure that you're basically using your local copy of coding in all of your vagrant boxes hence SSHFS among other things but um it's um the problem you're going to run into there is that that vagrants quite well it's two things it's very opinionated and it's quite limited um terraform and and honestly its providers are very weird as in no two providers look very similar so you end up rewriting a lot of code just to to kind of get the next provider to work which is I think where a chunk of where the the current change is going and I'm absolutely not saying we should stop doing that we should start working on terraform instead I'm saying that I think a bit of development work on terraform might obsolete this in the longer term and that would be worth doing so so that's what I'm saying why I'm saying we should focus on the terraform stuff as well which would be quite nice um because we've also got the packet.net code which is separate again it's a third backend with its own set of scripts um and I'm wondering whether that could be terraformed at some point in the future um but uh requirement wise then well go on yeah so the problem uh perhaps perhaps there's a library out there which solves this but there's no terraform kubernetes installer so I have to install kubernetes using a set of scripts in order to in order to make it work so if terraform had something that would install a cluster for you then it'd be a lot easier to to just use terraform for the entire lot yeah but you I mean again you've already done that so um and you've done it in terraform as well for for one platform or another so the question is can we basically recycle that for every platform because once you brought a you know the thing about terraform that's specific to terraform is bringing the virtual machines or the hosts up initially but once they're up then every single bit of terraform should be the same for all platforms so that was the thing that I thought was exciting that we basically write it once and every time someone fixes it it sticks for everybody which is uh advantageous over like the two or three varieties that we have today but I agree it would be nice if there was such a thing as a kubernetes deployer but I don't think there's anything fundamentally wrong with the approach you've done already I understand so so your idea is basically to to extend out the terraform stuff that I did and have a target of a grant or target other or other things in an ideal world that's what I'd like to see yeah I mean I'm not sure how feasible that is for vagrant itself annoying because I know that's where we start and well most people have but let's just see what's possible I mean theoretically vagrant you can associate into a vagrant box so you should be able to make the terraform work and I'd be amazed if someone hadn't tried testing their terraform scripts against vagrant boxes so there's a bit of investigation hey Ian I'd be willing to explore this with you we're still kind of battling legal internally but uh you're a favorite guy Brandon and I have been working on some stuff exactly in this space with like around terraform and deploying kubernetes and things so um I don't know when we're going to be allowed to share it we're trying to hopefully get it in this first quarter but um if we do get the green light to open source that I think we could leverage a lot of that code if you want a conversation offline then we can see it rather than sharing your code you can at least tell me what your thoughts are and maybe I can steal your thoughts which are a little bit less um legally encumbered shall we say but um we we can figure something out one way the other I mean it just feels to me I mean I'm firstly I'm sure people have deployed kubernetes with terraform but technically quite honestly for the purposes we have then there's nothing fundamentally wrong with what Frederick's doing so um I don't think we're um I think this is in reaching distance I just don't know quite how long it would take to get it to the point that you'd want to develop that way but if we could get this running on you know aws to take one example and fine you well I won't say you can't have sri v and aws but it's not exactly easy to work with and it gets bloody expensive very quickly but but aws would give us the ability to do tests with more far more infrastructure than you're ever going to run on your laptop with a vagrant system um so you know there's some real possibilities there so is so action items is anyone want to take a look at some of this stuff I will post what I've got which is frankly embarrassing but it was heading off in the right and and I think it's more theory than practice I don't know how far tested I got um but I'll stick it up on my github and you know for the purposes of making it visible to people I'll put a pull request in um and then you can see where I was going with it but it may be that we want to dispose of that and start in a slightly different direction um but yeah and then I can take a take a shot with Jeff and we can see what we can do okay cool so I'll wait for your um for your github repo um okay finally there's some parity with the cross cloud projects since we're it's all built on terraform and we've been using that for all the cloud providers um including packet we've been a little bit with kivium in the past I'm interested in seeing the code once you post that up yeah it's nothing to be proud of let's be clear if you've got something as a reference wherever that is if that's out out on the on the web somewhere can you can you stick a link in the uh in the notes the meeting notes sure the code that I'm talking about is targeting the clouds so we we are using a lot of the other providers we're not currently targeting lib for so that's fine because that's only one little bit of the code that I have to change I just love to see your examples because we we should be well two things right I'm not very well educated in terraform so reading more terraform helps me understand how to write good terraform but um but the other one is that it's there's probably things ideas that we can reuse for what we're doing so awesome okay so we have uh nine more minutes um nuklai do you think we have enough time to go over the roadmap or maybe what we should do is just uh start talking about it initially with with some of the high level stuff yeah yeah that's a that was actually the proposal to just bring up the topic and say okay we really need to to start defining at least high level goals of or maybe some milestones like uh cube com for example uh or things like that and say okay we want to do this by by this month and try to achieve it I mean and frankly even just collecting the list of things that we could be working towards is a good first start and then make sort out what are the orders and and what um you know what we want to try and achieve by when so for example um you know some of the things that have gone by I know we've got you know folks working right now on um the robustness story in other words making sure come back correctly when various components in the system die or at least just correctly as can be done um and part of this ends up being some of the stuff with auto healing um because it turns out that auto healing just sort of falls out when you make the system more robust or you would actually almost have to do effort not to um and then uh so that's one piece and I think that's that's kind of critical um then do we want to take notes on some of this so um robustness story auto healing as a part of that um then um we've got inter domain there's been some thoughts about doing um you know how to handle interactions between multiple uh nsm registry domains be things like uh multi cloud um etc stuff um we've had some discussion about that there's a whole bunch of stuff around what I would sort of call um deploy uh debugability yeah and the racing yeah yeah yeah yeah that's definitely um and this is this is basically this is not so much I'm a developer I can debug things it's more of a I have a production system and something went wrong what the fuck right um I I know Jeffrey has no idea what that's like um so definitely um definitely open tracing is something there and I there's some work underway um the other thing that that comes immediately to mind is IOAM um because I think we may be able to use um IOAM to do open tracing style things at l2 and l3 so we could actually do some of that because you're gonna have as the as people do what's going to come naturally which is balkanizing to more and more microservices you're going to want to know where things went um so you've got that for the debugability deployment there's also security and I tend to think of this in terms of um how to properly um authenticate and authorize um to access an nse is certainly one aspect of it there are probably others maybe connection encryption on data plane level data plane connection encryption I I would actually say that's probably a thing but I don't know what it looks like yet which is why I'm going to stick to the question mark there um that one that one's a tricky one because it's something that you'd expect the service to provide but um there might be a question about how to advertise facilities like this is an encrypted connection and it's an encrypted connection you're looking like you're looking for so yeah yeah so I know that there's interested interested in things like SRV six um MPLS so GRE uh or just straight MPLS yeah yeah yeah I did there there's there's so many ways that mom might do the um MPLS stuff um although for me and straight MPLS is MPLS yeah so there are two things these are remote mechanisms um not payload um so I you can imagine MPLS is always going to go over at least something like ethernet right but yeah but that might be physical ethernet and therefore you might be right down the down to um you you know down to the wire at that point um and I think um we we've had this thank you for saying that hardware support so not just the nick though that's my point it can also be um the thing that the nick's connected to if you're putting a data plane together um and the data plane does the x-lan that's great all you need is layer three connectivity now is layer three connectivity a thing you have normally yes but if it's MPLS you need more than just layer three connectivity so we can't pretend that the hardware isn't a network service or might not be a network service in its own right that other network services consume uh we've we've got to remember that that everything is it's got features and maybe it's got all the features we're looking for and maybe it hasn't and maybe we should be asking before we make assumptions yeah yeah no no I I like I'm I totally get that um so basically when I say hardware nick you know I mean not just you know the sort of nick there's there's pfvf sorry ov port making sure we've got the the right kind of space left so we could do things like when it comes up which looks quite interesting so there's definitely some stuff around that um yeah but I'm saying that it's not just the nick it's also the the fabric that the Jesus Christ I can't even right fabric I tried to capture that with the torque work okay well that's not an export is it then also don't don't forget things like the create verb and things related towards um auto-provision and so on so I'm I'm a huge fan very happy about create verb yeah what's the create verb for the uninitiated you're talking cryptic um so right now in the network service when you specify a match in the network service um the only verb that we have is route which basically says okay if you match this please route me to a destination that that has church that has labels that match and that's a super powerful um super powerful verb um there are two other verbs that we sort of hummed a few bars about in prs the first one is the right verb which is basically saying okay somebody asked for this network service with these labels um but you know the world has shifted and their legacy and so please rewrite them the request a little bit this way and then reprocess it right um the second one is the create verb which is super sexy because the create verb basically says okay um somebody asked for this network service please you know please create a network service endpoint and then connect them to it and by the way here's the policy about you tear it down win something like you know a minute's idle and this is passed for nobody's connected and um the create verb basically allows us to dynamically create network service in points on demand which becomes super super interesting in lots of cases not the least of which is edge okay that's not the way i would view the common model of service discovery we have but okay i think i see where you're going with this i'd like a longer conversation on that and that's not one that we're going to manage in the remaining time today i agree there are there are issues that hum a few bars about the create verb stuff if you want to go look for them um so they're fairly recent so i know there's interest in the create verb stuff i think we're right up against the hour um are there other things we want to kind of add to the laundry list um yeah i'm i'm gonna turn all this into a word or sorry a google doc and that way we can uh put links to it and all that kind of stuff and i think some of the roadmap items that we're talking about uh may not end up fitting the github issue stuff so it might make sense to keep it as a google doc but uh if it's basically um brainstorming ideas then a google doc's often better for that anyway because you can edit what's there out notes it's just much easier to then send a string of comments so it makes sense to me yeah make a selfish request sure can instead of just strictly frv6 could we just look at segment routing holistically um because different parts of my convoluted network are going to implement sr in different ways so that's why i asked for just straight mpls do is i would be very interested in not just srv6 but also sr mpls if possible and and mpls is a multi-tutor sins as well because you've got a data a control plane that goes with it which varies but it's the the point is that we need something which is an abstract description of a connection and the more examples we can throw at it the more sure we can be we've got to the abstract and not we haven't made assumptions about the data plane that we're talking about and i hesitate to use the word data plane because that's not necessarily what this is going to be but you know well we're we're out of time but what i recommend is we add this to the uh to the next week's agenda we can discuss what this really means uh i think i think the short answer is going to be that well i personally think it's a good idea and with that um thank you for attending the year's first meeting the next meeting is going to be at the same time in about one week from now so thank you all and um catch you next week cool thank you guys thank you thank you everyone bye bye bye bye happy new