 If we could get someone to share the the agenda that would be that would be great and so we have recurring this particular this particular event which occurs every Tuesday at this time we have the NSM document call which occurs every Wednesday at 8 a.m. Pacific time and the NSM use case which occurs every second fourth and fifth Monday at 8 a.m. we also have the CNCF telecom user group that we attend which occurs on the first and third Monday this Monday we should have a telecom user group call coming up the link is posted on the agenda notes we also have a telecom user group kickoff meeting coming up in Shanghai China and that'll be on May 23rd at 12 30 p.m. sorry at 11 or 5 p.m. and it lasts for an hour for roughly an hour and a half we there is also a CNCF networking working group that occurs every two weeks on Tuesday at 9 a.m. we have the Cisco live going on right now and where Sergey is leading a one-hour breakdown of NSM and that is going to occur tomorrow does anyone know where Cisco live is located as well or is that a is that a podcast no Cisco live is where is Cisco live I want to say San Diego but maybe I'm misremembering it's currently happening yeah and San Diego right now I don't know what the deal is on the posting of videos but we can definitely find out cool we also have kubecon China coming up on June 25th through June 26th it probably is I just got a message saying my internet connection's unstable oh joy that's always you want to take over for a short while I will switch to a different internet connection sure absolutely so let's see we were talking about kubecon China so we do have an intro maintainer track taking place at kubecon China that Fredrick and Nikolai will be giving so please if you're going to be going to kubecon China do turn out for that we have there's an upcoming event dpdk user space that's coming up in Bordeaux France I don't know that we have anything directly at a some related going on there but definitely good folks open source networking summit Europe is coming up in Antwerp Belgium that CFP is still for a tiny while still open and so if folks would like to go and submit an NSM related talk there we would strongly encourage that so just an update yeah we are planning me and Taylor to do something related to the NSM enablement and the CCNF testbed let's say perfect that's excellent yeah and also I was last I guess not on the call he is going to post the talk about his experience with bringing up with like enabling the forwarder with the pure kernel kernel based on which is still ongoing but you know how these things work it puts a deadline on it for him right yeah I know I'm very familiar like you know it tremendous percentage of my life in the last half decade has been driven by conference different development so you know this is this is that's also a good idea I mean the good news is there's a very high probability of acceptance I think generally speaking network service mesh talks have been some of the most highly attended and you know basically most look forward to talks at open source networking summit so I think we got a very good chance of being accepted there well awesome and then you know and also on the that whole work you know Rattislaus been doing great work at making sure we got proper separation between things so that you know the promised the APIs for the forwarder being replaceable are actually true I think the last one he found was with some binding in the integration test which means that he if he's down to that point then good progress is being made yeah I mean it's on one hand yes there has been some some bindings here and there but on the other hand like it really helps out the design was made right from the start to have the separation so some things have leaked over time but not really like a huge deal of you know refactoring I mean I tend to view it this way right when I think about bugs I think about design bugs and implementation bugs I'm not super concerned about those just get fixed yeah design bugs terrifying because design bugs typically get harder and harder to fix with time it's the fact that he's not hitting any serious design bugs is really comforting so cool cool so we've got QCon North America coming up in San Diego in late November and that CFP closes July 12 we really probably I know in the past what we've done for a QCon is we've often put together a page as a community where we sort of brainstorm together on talks that we can you know we can various people can propose we'll probably gonna want to start doing that here again for QCon North America yeah you know no time actually I was thinking that it's kind of throughout summer but yeah this no it's it's it's close it's super for those of us who've been doing this a long time it's super hysterical because I think it was for QCon Austin the CFP for QCon Austin was open for something like 14 months I have no idea why it was super weird back in you know QCon Austin 2017 and so it was just it's funny that they've gotten to be this tight but you know it's a great conference and a really good audience we had a really good time at QCon to you and QCon North America the last couple times so yeah so I mean just about it is like as we said already I would really really want to go for a longer like single longer session than the two shorter ones but maybe that's I mean that's something no I mean I'm quite honestly I see the wisdom in that suggestion and and you know that when we got a little bit more space and time on because that comes down to by virtue of being an ever a CNCF project we do get either two shorter or one longer slots at QCon for use by the project but I'd love to also get some things into the normal CFP process oh by the way I don't know if we have added here but there's open source summit in Lyon in Europe which is maybe before QCon North America and I was planning to submit it's by the end of June yeah let's go ahead and get that out of here if somebody could get that out of here that would be great I'm open it used to be Linux Summit and now it's open source summit and so the flavor's got a little bit broader the few times I've attended I've been quite pleased with open source summit it's a friendly bunch yeah I've I have submitted that I have a connection again so I have submitted something to the dbtk user space in Bordeaux so I put something there about integrating the integration story between NSM and dbtk in the same light as what I did at the fight out except focus is on dbtk instead so I will let you know what happens if or when I receive notice on that I think OSS is sometime October maybe so June yeah cool and then we've also somebody's listed out edge computing world in Mountain View and that's still but probably a good place to talk as well and as always please add any events that you've got an actual confirmed NSM presence that please push a patch to the site so we can get them up there because that's we're trying to make that the point of reference for folks yeah the edge computing world hasn't been formerly announced yet which is why the website is to is not to be announced by us to be announced by the actual organizers so but they asked me for help with like with their there's you'll be an inaugural event and asked me for help to to get to get them to focus what should they focus on and what should be what should be accepted which traction they have so I'm helping out helping them out with some of that stuff so sounds good cool awesome so do you want to pick back up again Frederick now that you're back on the call sure and let me know if it's acting up again I'm now on my cell phone connection awesome right so we have the social media community team Lucina I think I saw you hop on so you have a fork hello yes this last week has been pretty productive for the end service mesh Twitter account we gained six followers followed 80 more people and accounts and submitted 22 tweets and retweets there were some interesting things that popped up there was a request for a mention rather of network service mesh regarding the OBS orbit podcast there's also a lot of discussions about service mesh in general on Twitter whenever I see something that looks interesting I'll just post it into the slack channel for anybody on the slack channel to interact with or let me know if there's any way you would like me to interact with those things other than liking or happy to like and retweet so somebody should probably reach out to the OBS orbit podcast guys you know I think you're probably in a particularly good position Nikolai since they're also at the hardware yeah I mean Fred has reached out and yeah okay I dangled Nikolai in front and they're very receptive bait but okay they were Ben Ben has I've known him for a long time as well and he's he's been interested in new content and this is something that is obviously very new and I think the fact that both me and Nikolai know Ben relatively well is a bonus okay so and he knows about the network service mesh already I think about you yes I have no idea if he knows about service mesh but I'm sure between you and Frederick you can fix that yeah I think I think he knows of it but I don't think he knows what it is but but I'm sure he's heard some some people speak about it I mean okay he knows what I'm doing let's say good and then this has been this cncf webinars that I have been pointed to and we had I mean we changed some messages with to see him about it and she was trying to find that we have two ways to actually engage there one is open a ticket and the other one is send an email and I know someone told me that this schedule is pretty tight for the months to come but maybe we can do something like September October something like that that's actually pretty good timing going into QCon frankly and by then hopefully we'll have some of the inner domain things working which would be kind of awesome so that that's not bad timing for us frankly so how do we want to approach this like I don't know do you see I haven't watched any of the webinars but do we want to approach it like three of us or we just elect someone that is you know doing the webinar what what do you guys see feasible I mean so I think like the first step is I think you've sort of already stepped up and taken a bit of ownership here Nikolai if you'd like someone else we could get another volunteer get it on their radar you know by opening a case-to-service task and just sort of I presume there's a way to add in okay and then from there we can figure out sort of what the timeframe would be and figure out what we want to focus on in that webinar when we get there okay okay let's do this I will create the tickets I mean it's better to have it publicly available for everyone to see otherwise with males you know yeah okay so I think you can always delegate it to to somebody if someone wants to take over and do the actual content so someone wants to write a blog poster or something similar like I think the ticket has to come from us but I think that we could hand off the actual task to to someone else and get their name on it yeah and quickly I think the only reason the request needs to come from you know Nikolai Frederick myself or Andre is just because then they actually know we are representing the project it's asking a little bit for them to track all the participants in a project they can usually just track the the maintainers yeah although I wouldn't mind if they if they left it open for people to post and then they can have us just review and say yeah that looks reasonable they probably do we should talk to them about how that works yeah because I don't want to have to open a ticket for every single person who wants to talk I because it makes us the bottlenecks and and we shouldn't be bottleneck in the community okay at least not okay so release notes so I am going to bring the release notes up to the next document but here's a here's a question do we have a do we have a tentative date on when the 010 release is going to occur no we have the discussion of the drama release does that make sense yeah yeah I think that's a that's a good idea but in short I'm going to bring the release notes up to the documents called tomorrow and get a start get us to start filling it out again for the components okay let's do that okay so then let me take over for them and I'm not there's nothing I mean I don't want to share I think I just let me let me talk you through what what what I think about the release currently so the branch was done last week I think or the week before that okay I forgot really last week I think yeah I know it seems like it's her day okay then there are some challenges there like our default I mean we have a lot of assumptions within the the code like for example not the code itself but maybe the surrounding scripting like our health charts there's the version but I think that by default I just default to latest so you either need to specify it explicitly the version so that's that's probably something that that we need to figure out because currently the situation is like this so in the main branch everything is about latest while in the branch we either go and manually or by script just change everything to the branch release or I don't know what are our other options mean like we can have some automation that actually tries to figure out are you on a branch and if you are on a branch then it changes things I don't know because it seems like there's a lot of manual work and if not not a lot but there's some manual work and if there is manual work then it's error-prone you know people etc etc so the other things I would suggest that we consider is right now we're dumping everything including our CI stuff into the one great Docker guy yeah and it strikes me that that's a unfortunate historical accident it would be really really nice if we could get a separate network service mesh CI registry clean out the old one and only put release things in the public-facing registry that would be great and I know that they're so Frederick you know the doctor space super well is there any reasonably automatable way to clean out old entries from old label entries from a doctor registry like man percent of them like I know I can go through and click them one by one but that's that's I've actually gotten to the point where I have briefly considered deleting the registry and then recreating the registry I was I was okay maybe Fred is there again what I managed to find out is there is some curl magic that you can send and if you do something but yeah there you could all there there is curl so basically the Docker the Docker API hub API is basically a rest-based interface and so we could write a script that that does it rather than and I'm sure somebody's written one on stuck it on to the internet some guests somewhere yeah there'll be some because they'll be others are the same and I think it comes down to Docker it Docker gains more like it's sort of like stars on GitHub you know it's like how many stars you have and it's like yeah it is a metric of like your project is growing but it's like but there's other metrics you want to track instead like downloads or or so on depending on the type of your project and it's the same with with Docker it's like okay they can post like we have these many million images and so on but it's like you know same they don't want to make it easy to delete everything yeah okay so I guess that the first step would be can we get our CI so that it publishes to a network service match CI registry I know create one and get the credentials in place because that's sort of the first step once we've made that transition then we can say okay how do we clean what do we want to do by cleaning up the network service mesh repo okay that could be tricky because this means that we need to redirect like the tests and stuff I mean everything is essentially downloaded from like we should be able to Andre how hard is it to redirect the test to a new registry maybe I don't remember should not be a problem actually I think okay since we could use for tests we could use a prefix or registry we want to take vertefacts so for tests I think it's easy yeah I mean the problem is with the testing only like everything else should we will stay on the original the release registry you want to call it like this yeah so let's let's do the following I'll take an action item to go create the registry and the to go create the registry and get the credentials in to circle CI and then I'll take it open a ticket they're all open a jara issue to migrate over to using that does that set reasonable yep okay and that's sort of a good first step towards actually getting the mechanics in place yeah my suggestion would be we clean out the network service mesh repo that exists right now we push whatever is a reasonable latest to latest just in case other people are kicking the tire so things won't break yeah you will get the latest as soon as soon as you run the circle CI master and then you get latest that's yeah yeah but well that latest will now be pushed up to the CI repo because we're I think for the network service mesh repo we only want to push the release things right generally speaking oh no no latest should be no I think that I mean so in the CI we need to push only the images that we use within the testing and then they should be the latest which actually reflects the status of the latest master I think that okay no that's fair so if you're saying have latest that reflects in this that there reflects the latest master I can live with that that's perfectly okay with me we just needed to actually come to agreement about that if that makes sense yeah so I'm perfectly fine with saying we'll always push the results of a successful master up as latest and then we can just tag the things that are particular releases if people want to attach particular releases that seems okay to me then one more question because I now I have the release branch and if I build something in the release branch there are chances that I mean I can push images there from the branch but because they are not tagged I'm not pushing anything so does it make sense that we have the the same way that we have latest reflecting master does it make sense to have a release branch named like release dash 0.1 images sitting there just reflecting the status of the latest yes but I wouldn't name them that because that's gonna make people think that it's actually a released image yeah yeah so I mean I could see like I could see putting something in there yeah that that's you don't want to call it latest as to 0.1 because then people will think it's the latest and not the release so I think we need to figure out the naming but I think your general notion is correct so which which repo is this is this like a test repo or is this an actual release repo I think we were talking about the release repo because my initial question was for the release repo we only put release artifacts in the release repo and then we have the CI repo where we keep the other things and Nikolai suggested that we have latest in the release repo be latest on master is there actually well established best practice here that you're aware of Frederick yeah so in the in the main repo we want the the latest one the default repo just to be the production quality thing that we want people to ship with because what some people will do is they'll just tag they won't even put a tag in they'll just put from network service mesh or they'll stick network service mesh without a without an actual version number so we need to make sure we always give them the latest and it's very common to see version numbers actually tagged like they'll tag it like version one they'll use semantic versioning so version one 1.0 or 1.5 or whatever it is and then and then we can tag 1.5 point 1 1.5 point 2 1.5 point 3 or short so on so they'll they'll typically tag the full version and then the version minus patch and version minus minor in patch so that way they can peg to their to their comfort zone and beyond that it's very similar like if you look at the G go repo that that's pretty much what they do be beyond beyond that I think we can we can be more experimental with the the CI and learn a little bit more but I would definitely recommend trying to stick with that style in the in the main release repo okay so that are you saying that there won't be any releases from the branch unless there is a tag in it and like we only release the factory so we have latest and then the actual semantic version that releases from the release branch but nothing can be yeah but what I'm trying to remember is whether latest implied default or whether there was a default tag and that's what I'm trying to remember latest if it's from master that's that's fine as long as it's not the default branch and so that's the one semantic that we need to to double check on but I think I think colon default was the default branch and colon latest is something that is arbitrary but I think we actually do get people that I've seen a very common habit of people making latest the latest release version and so you do get a lot of people who will simply point to latest expecting that kind of default behavior that you're referring to yeah and I'd be more comfortable calling it literally calling the branch master so if you want master tag to master don't and I think that'd be a good mark there that's that's that's a good idea I mean if we could we could make it even more explicit and make it branch dash master branch dash dash um v dot zero dot one that might be particularly clear yeah and what's what's nice about about the version in numbers is that suppose that we release version two right and we're working on version three like default goes to two but version three is and master can be the same and so we can actually have master just point to uh to three tag effectively whatever it's latest theory about tying a release tag on something that's not released yet though yeah that that is true it went the the one problem that we'd run into that is is potential caching problems where someone pulled something and um then once it's in the repo there is a policy where well I mean push where you pull if unavailable you can also run into a problem like a lot of times when I've done to docker um I will go and I will look for the latest release release looking tag and I will grab that and if we put a release looking tag on something that is not actually a release thing people can grabbing something that isn't a release thing thinking it is yeah and that's why I would prefer that that stuff live in in another repo but I think colon master should be should be fine like it's it's pretty clear what colon master is and if you decide to use it then yeah you know the implications are Nikolai how would you feel about the following which is we have the ci repo we have the release repo in the release repo latest points of latest release artifact we tag release things when their actual releases and we have a master tag to follow master um and then for the throttle branches do you mind the throttle branches uh getting stuck in ci on publish in the ci repo in publish or what's your feeling of thought here what are the throttle branches sorry i'm not sure uh things like the release slash zero dot one brand oh yeah yeah yeah and they will leave where sorry in the ci repo oh yeah okay yeah yeah I can imagine people wanting to yes yes yes yes perfect perfect cool awesome Andre do you have any thoughts on this or does anybody else have any wisdom to share no I'm okay cool sounds reasonable quick question I want to be able to publish I think that I already have put some code in place to publish the images that I produce in the examples um like my only wish is to have just the latest or the master ones so does it make sense to put them in the main repo we have a separate examples I mean I I don't know no I think I think it makes sense as long as we don't expect any name collision with the example repo I think it makes sense to follow exactly the same pattern for the example repo images um and you know put the ci things in the network service mesh ci registry put the release no there are no ci things no no I I tested everything only in-circle ci in kind that's that's that's good enough for me for now and then don't do any testing well okay that's that's that's fine so I mean you know if they're actually release versions of those things or if it's something that's chasing master I think it's perfectly reasonable to follow the same convention we're talking about the same okay perfect I like things that are consistent unless there are good reasons for them not to be consistent then in this case we we what we say is that there's not going to be any latest stack well in less than until we have release versions of the example okay I mean I could easily see doing release versions of the example network service endpoints but but but I think latest should probably point to a release something generally speaking at least in the network service mesh repo yeah okay good we are aligned there it's good to be an alignment I like yeah particularly alignment that comes from hashing through the issues and I've got a good rule of thumb which is if we arrive at a solution that is not the one that I would have proposed off the top of my head we've probably given a good consideration so um anyone else want to dig in on this at all before we jump on to the next thing okay the next thing is the road map mm-hmm so I finally had a chance to actually watch through the full tu g kickoff meeting where actually there was a one ask from Dan about us having a road map doc like somewhere in the repo that we track what we plan to do in the next you know three to six months mm-hmm so maybe it would make sense to reflect this somehow in a in our spec and then probably link to it in the main read me just for the people so I mean one of the things I've been trying to do visually for that is if you go down to the attempt at network service I've actually been putting that up there and it's it's not fully complete yet I so if you if you're like where's my thing the answer is let's get your thing there but I've also been trying to go and put into them that go to the issues for the specs around them so that if you're sort of like okay what are they doing around that you can actually get to it um so do you think we can just link straight to this or we can just you know export this as a png and then just keep it in the repo and then we update it once we update this guy here what what do you want to yeah I'm I'm I'm up for embracing the healing power of and there um so I think you know we can definitely do that um you know it depends on how much we think this is going to be a live document for the next little bit um you know because my guess is that you know it will be a live document for a little bit because I know we for example we have specs that are not captured here and we have things captured here that don't have specs yet um and we need to sort of figure out how those all fit in together um so maybe starting by linking to here would be a good start also like you know I tend to think in pictures and some other people think better in terms of text um so it might be worth bouncing off the documentation group to see if they have any opinions about how this might be better represented yeah and also is that is there a way to tick off things here like you know we already have the nsc monitor from what I know um no we actually don't think we have the nsc monitor yet that was the notion of an idea around resiliency v2 um yeah I mean we have uh the monitor client for sure but yeah you might be right we don't have like a oversight card that happens yeah right right um I mean I would definitely say like we could just get a little check checkbox image and attach them here as we complete things um because I know there's some work underway on security um I think there's some work starting to get underway on DNS um you know so you know that there's there's some forward progress I was just talking to someone yesterday who may turn up in the community to start working on the sessions payload stuff and I would love to wanted to if there are people interested in contributing who wanted to sort of contribute to any of these areas that would be super welcome more of the barrier and then like I said there are some other things here that are not clearly represented like I know that there was a there's a very interesting conversation happening around um possibly more sophisticated um selection algorithms than round robin once you've got a class of candidates um and that could be super interesting as well so how how do you do we have because uh the specific us from then was like three to six months or do you see these things through three to six months because probably it's a little bit far yeah I I definitely think for a lot of these things um you know like security inter-domain probably all the way through hardware mix I think it's probably stuff we're gonna want to do in the next three to six months but like everything it depends on who turns up interested in working on what in the community you know I mean if this is always this is the age old question of open source projects and people asking them for roadmaps and the answer is sort of it depends on who shows up and what they're interested in yeah I don't know what was your experience last summer but at least the northern hemisphere goes most long vacation for the next couple of months so I tend to refer it well in the US we just don't take vacation okay but Europe Europe is a satyr and we're civilized place and so my only real complaint with general european saturday around summer vacation is it would be convenient for the rest of the world if you would all take the same month off in the summer instead of mirroring it across the continent no we take the same three months it is it is a little exhausting in north america figure out which country takes which month off in the summer i get eight hours of vacation every day yeah no i mean um clearly your employer is very liberal in the US i only get um so i mean we like is it next three three months it means like by september we do you think we will have some of these i know that you know there are various people who think on various things i mean i'm i'm just seeing what ever happens with the world goal with group co-attendance like it's like people i guess that are traveling or taking time off so we probably will get some low on attendance too that's i think that actually i think that actually is probably true so i mean here's the thing i would suggest like this actually gets to a higher level conversation which is do we want to do time-based releases or do we want to do feature-based releases um i tend to in open source communities i tend to prefer time-based just because if you go feature-based then all kinds of weird stuff can happen because of varying participation um but i'm curious what other people's opinions are well i mean we had an attempt to to to uh align the our releases around kubicon uh-huh these are kind of you know six months so yeah i don't know this is a little long i mean how do folks feel about quarterly releases um how does how do folks feel about that i mean we want to try and make sure that at least one of the lines up with kubicon stuff at each six month fall but um generally quarter releases is often a good cadence yeah and thanks for putting it as ideas because i think we're just stifling right now i mean please note like time-based releases my experiences particularly as projects grow they become sort of roughly time-based um Kubernetes is roughly quarterly um but you know eventually you get better at heading your time i know for example like the eclipse project test like for 15 years hit its dates um a very complicated show of things that go into it so let's say we got some comments in the chat on liking time-based okay conference driven childhood things i i love that term nicole i've not heard it before but it so describes my life i don't practice agile i practice conference driven development yeah uh then it's just a matter of having uh conferences more often right i mean like there should be more confidence in the summer like i mean they would except that the varying parts of europe are on vacation at that time okay yeah i i just said i i radically agree with the civilized civilized behavior in europe it's a little rough but it's varying months yeah cool okay so uh around the roadmap i think that that we more or less are agreeing on what should be there maybe there's no point into continuing to to put it up front again uh like to put it on the on the discussion here maybe we should try to converge maybe tomorrow's work the documentation call on how we want to expose this to the world in our repo etc etc i think it's probably worth keeping open uh of you know a very simple item for roadmap editions yes we'll have a really good place every week for them to come in and say hey i think we should probably do this um you know because i don't ever want it to feel like oh the roadmap is set in stone for the last nine months so come back then that i don't know for what to happen oh okay so we actually we don't have anything else on the so maybe maybe i can bring up a topic so uh if no one else objects i mean it's not on the here i think that i'll finish the agenda is whatever someone scribbles down on the agenda so yeah okay so i spoke lately to a guy that has very much experience in you know bringing up open source projects etc etc i mean this could be okay uh essentially it was a guy from hardware project so so it's a project that actually graduated since yet etc so when we were speaking when we end up talking and he gave me an advice like if you want to move to the next level like you know from sandbox to incubation project one thing that you should like look for and try to move forward is adoption like someone should start using this in whatever form like there should be someone maybe i mean optimistically a couple of them but okay let's let's say that we won't do one guy for for the time being so i think that we should kind of open the discussion of who that guy could be like at least in what domain and what we want to see and try to look for someone to really i don't know earn it somewhere i know that it's kind of early maybe it will take us you know maybe next couple of release cycles etc etc but maybe if we start discussing a lot identifying who that guy could be i don't think it's too early to start talking about it i think it's actually really good to start talking about it let me take us a little bit more time to actually get something to deploy but i mean it's almost like a user persona kind of conversation what are the kinds of users because we've had some discussion about use cases but you sort of look at user personas and so for example we know that there's a lot of really interesting stuff going on here for enterprises for sort of multi cloud hybrid cloud behavior right so we've got a whole bunch of stuff under enterprise customers and then we also know from our friends in the tug that we have some sps that have similar kinds of problems that they need to solve for cloud native nfc so that's that's two really good groups right now right there off the top and i suspect you'll get some personas under that that we can work out as personas and then just sort of figure out what's the minimum viable set of things that those personas need in order to be able to do deployments i think that's probably good advice i mean harvors advice is excellent here i know for example one of the requirements to become an incubation project is we have to have at least three deployments that are willing to stand up publicly and say yes i've deployed this at least my approach currently in what i'm trying to do and push with with taylor and the other guys from cms test bed it's like if we have this very first like continuously tested and verified deployment in cms test bed it's kind of an old jump start or something that you can refer to and i don't think that's i think that's excellent um i think that's an excellent start particularly for the sp customer persona um and i would love to see that come together you know hopefully in small quick steps right so i think we can do a lot with it i'm sort of thinking in terms of like what's the smallest thing that we could do with it so i was looking at the at the cncf dashboard i think that the guys from vogue should probably tell us but would it make sense if we want to run something there i mean what's the status of the cn i saw that the latest kubernetes is 1.13 is it something that that people are looking into i mean does it make sense for us to also try to go there with some i don't know whatever this is watching yeah the dashboard we're going down from graduated and incubating down a certain path so yeah yeah okay so it's too early for us okay yeah ideally at some point there's going to be a screen story we would show um use cases and my projects that's not something that's seen there but it's something that we've had kind of in in the back of our mind um yeah interoperability type views and stuff and i think at that point you could see something like in a sim being used on a for those use cases similar to what's seen in the scenic test bed is yes that yeah yeah you would have a view and then maybe nsm would be running in and ideally with other cncf projects so that you say here is here's a kind of a reference platform where you have these the different software running yeah in a demo of that and and then some type of integration tests that go through the whole platform yeah because we actually have in the examples now we have envoy enablement on top of you know nsm which is kind of in line with this and also as you said we have cnf test bed but it's mostly tackling the specific use cases and if we want to have some adoption i mean this will probably be i mean we have probably higher chances in some kind of enterprise-ish type of workloads so we'd better have something that we can demonstrate that this works in a verified way not something that we keep in our own ci on the stage you know deployments etc but something that can be exposed more i don't know openly and you know i i think um as far as something that would be seen sooner would be on the scenic test bed and if we can come up with functional type use cases where we say here's different parts how they fit together in a something similar maybe to what the onap vsp use case is it's trying to show a a specific type of functionality that's desired so if if there's something that you or anyone else um think would be really interesting to a larger group or a specific group who may want to contribute then we can design that um probably building off of stuff that we've been talking about the last week and a half yeah yeah okay makes sense i mean because all like when you say cnf test bed it kind of implies cnf deco uh sneaking networking that comment is going to be with us for a long time yeah um right now i don't i don't know of an area where that the naming or whatever is open so not vendor specific or project specific and not i mean even the cnf test bed in my mind should probably be renamed to something like cloud native networking test bed and we're not working yeah i would be super cautious with that right naming just because right now there's a huge gap between what sp means by that and what enterprise means by that one that we're hoping to bridge and so you know what what sp is asking for literally is completely alien right now in the lines of the enterprise guys so they might get a little bit agitated i understand and yeah i don't i don't want to definitely don't want to rename right now i'm just um highlighting i agree that the naming doesn't work for everybody probably just if we can start documents and the conversations with who's the persona and the viewpoint that we're taking right now with whatever the demo commentaries use cases are and it'll be helpful for everyone um yeah so we're hitting the top of the hour are there any last things we want to talk about before we before we conclude great well with that thank you everyone for attending and we will see you all again next week enjoy the rest of your day thank you guys see you bye bye yeah cheers