 Let's see, the time is now 9 o'clock, shall we get started? Yeah, I think we can start. Great, so just a reminder for those who have joined, please add yourself to the attendees list in the agenda. And can someone post the agenda link one more time just to make sure everyone has it. And with that, we have a set of recurring meetings. So we have this meeting, which occurs every Tuesday at this time. We have a NSM document meeting, which occurs every Wednesday at this time. And we have a use case document, which happens every second, fourth and fifth Monday at this time as well. We are also participating in the CNCF telecom user group, Birds of a Feather, which happens on the first and third Monday at this time as well. And finally, there is a CNCF networking working group, which happens every two weeks at 9am Pacific time. So we have, so we have just completed Container World 2019. Oh. So, Prem, was there anything that actually, Prem, we spoke about that before, didn't we? Yes, that's right. I'm going to remove that off the agenda. Interestingly, there's, at the upcoming Docker com, there's a person who I think is going to mention Network Service Smash, but I don't think there, we don't have anyone who's giving a proper talk there. Right. I think they are organizing a two to three hour session. And Lee, who is also running the machinery, he's basically doing that. Yeah, so I saw someone from my share, I believe it is. Yeah. Hey guys, yeah, I have joined the call. It looks like Lee has been talking with Prem and Ed. So, you know, so when you have a chance, like, you know, let me know, and I can actually use the machine project. It's, it's, you know, it's, of course, like, you know, it's very early stages, but, but definitely like, you know, we're trying to actually take it through. I'm not sure, like, you know, if you guys have some background, but you know, so when, I mean, as you guys go through the agenda and like, you know, when you guys give me a spot, I can talk about it for about two or three minutes. Perfect, perfect. And that's super easy to fit in. I would actually suggest maybe we do it before the logo conversation, because I expect the logo conversation to be part of a non-consuming sort of way. Okay, moving. Yeah, and you know, historically, especially if it's in San Francisco, I'd join in and help out in a physical presence, but I'm not going to, I'm currently out of town, so it's possible, we'll get to this though. So we have KubeCon EU showing up with in Barcelona. And so that is from May 21st to 23rd. We have an intro and deep dive. And there is a potential elephant demo booth that we may end up doing in conjunction with ODL, I believe. We have on May 20th, the day before, we have a few co-located events at KubeCon as well. So we have the, we have talks in the FIDO mini summit. And we have talks in the Cloud Native Network Service Day. We have KubeCon China coming up as well in June 25th to 26th in Shanghai, where we have an intro talk in their maintainer track. We have ONS Europe coming up in Antwerp with the call for paper closing in June 16th. So we have MEF 2019 in Los Angeles. And I believe there's some presence that there's going to be there for some part of the community. At the exact same time, we also have KubeCon North America in San Diego where the call for papers opens up in a few days in May 6th. So if you have anything that you would like added to this events list, definitely let us know and we'll add it in there. And with that. One last thing on, one last thing on the events. I dropped a link both for KubeCon and also in general at the end, as folks actually get things lined up for events. Please feel free to push a PR to the site to update them, particularly on the upcoming KubeCon to you. So I know quite a few of us are looking to place, you know, booth demos, talks. We've got the general talks, we've got talks at co-located events. And so just feel free to push a PR and add whatever you're doing related to network service mesh there to the site. Yeah, so one of the nice things about our site is that you add the metadata with the time and in the date. It'll order it properly in the events page and it'll migrate it to past events once it's a past event. It's super easy to add something in. It's just copy over one of the templates, modify it, then you're good to go. We have an announcement from Nikolai. So Nikolai, you have four. Yeah, it's actually from the core team, let's say, from the core contributors team. And I have the honor to announce it. So we had some discussions last week and, you know, we are now part of CNCF and this kind of makes the project kind of is a sign of the fact that the project is more important. Then, I mean, it's a really big thing now. So we had kind of a discussion with Fred and Ted last week. And we agreed together that we would like to have a person from the community promoted to join us within the core contributors, like the guys that have right access to the repos, to the main repos of network service mesh and the site. And this person's name is Andrei Sobolev. So he contributed more than 40 patches lately. He's a great supporter of the stability of the CI. He helps with reviews and in general takes care of the project being stable. And we recognize him as a key member of the community and we hope that with this we will have a more stable project and we will boost the project to the next levels. Yeah, thank you guys. It's very nice. Congratulations. Congratulations. Yeah, thank you. Congratulations, Andrei. So, yeah, so that's more or less the announcement from me. I don't know if I have something to ask, but I will enable your admin access just after the call. Cool. And I'll start trying to remember all the other places I need to add your admin access. Yeah. Yeah, and I'll tell you what I sort of told Andrei and Frederick, which is in principle with a couple of exceptions like places where there are critical numbers. I am delighted. I want to make sure that we all, all the, the committers have equal access to the resources for a management point of view. It's just generally good policy. But I'm not sure that I remember what all those things are. So if you come across one that I haven't added you to just let me know. Yeah. So you can, can we start on a new document that describes what all those things are? Yeah. Right. Good idea. That is a very good idea. Yes. Well, again, congratulations. Like for, for us, like this isn't something we ever, we take, we take lightly. And so you definitely put in a huge amount of work. And so definitely looking forward to seeing your, your future contributions. Thank you. So, so we have a network service Twitter account. So, Lysina, you have the, you have the floor to give the update. Thank you. Since last week, we've gained 42 followers. We're now at 157. And also since last week we are following 254 more accounts than last week. So we have 623. We're following 623. And I'm keeping an eye on the events to post about cube on you as well as FDI mini summit and the LFN cloud native services day. I'll post about those to let everyone know where we'll be at that at the events. And once the release notes are ready for the Andromeda release, I will also post an announcement for that. If there's anything else you'd like to see, feel free to let me know. I'm open to suggestions. I do acknowledge two things. Number one, that's a hell of a lot of work to make that much progress in one week. So thank you so much. But number two, you've also been posting like, all kinds of NSM related things like, I think there was a bit that the Prem had done on telecom TV that touched on an SM and you posted that. And so you just had an exceptionally good job of tracking all the things. And I really appreciate it. Thanks, Ed. You're welcome. I have a question. I don't know if I should share the link here, but it was shared in the general NSM channel. It's on tweet. It's about. Okay, let me just click here and I guess that we open. So, yeah, I mean, we live in a free world. Everyone can have his or hers opinion open shared. So my question is how in general do we handle all the positive and, you know, kind of not really positive messages that are out there, especially with Twitter. So I see that threat answer here. So there's a kind of small discussion going on. But do we want to have a more structured approach to this or we just let it as it is. I don't know how much of a structure approach we need. Generally speaking, I'm pretty happy as long as everyone keeps things kind. Yeah, really straightforward communication. So to work in his himself an interesting guy. He's always fun to interact with. My question was more about because I hope I, I guess that I mean, she probably mean, if you need some help or you think that there's some messaging that we can, we can, you know, send even not directly as a reply to someone else, but maybe as a kind of statement from from us as a community. Yes, as an indirect reply to something. I don't know, maybe, maybe you can just reach out to us and we can try to figure out. That sounds good. Yes, for the most part, this one that was brought up on the screen was one where it wasn't as simple. Thanks so much. We're happy to be included in the same CF, you know, so this one was like, Yeah, what One of the things about the scene is, is she's not shy, she will reach out. Yeah. Yeah. And great. Okay. My general policy when it comes to these type of things is always always be kind, like, even they even if the person and then and D work and was was not like this but you know, even if the person is extremely upset, you know, they're, they're angry, it's like, still be kind, you know, I, and so I think that one of the worst things we could do is is is to not be kind because that's not only does that not help the other person and or help us but actually destroys our reputation as well. And so, so I think for me that that's the that's the primary, like regardless to what form or structure that that it has. You know, that's that's the, for me that that's paramount that we that we act like that. When it comes to something like this, I think that once the once the website is a little bit more structured than something that Lucina could help us with is trying to identify the list of very frequently asked questions. You know, and we can point people at them, just to see the see the conversation and if it's not enough for them, then we can, then we, and then we can further join in on the conversation. So, but I, like one thing I'm hearing over and over and over again is like, what, how, how is this different is still why why not a sale. That to the point that I, you know, that that that could be the big the first question that we could add in is like, why, why not a steal for these use cases. But it happens to be a particularly good question because it was great at what it does. This is just different than that. Absolutely. And, and, and people are genuinely curious that they're not, they're not saying it like we're in a disparaging way they're genuinely curious like why, why is why is this you not enough in the space. Yeah, and as a follow up one other thing that I always get is some of people assume that it's right and they assume that this is also service mesh similar to a steal. So I tell them that hey there's not the regular service mesh and then explain them. Then people, their wall effect goes further. That's the feedback I got from people, hey, this looks interesting and then they start off getting to further discussion. I was just wondering, should we have an somehow right up between that explains what these two does and what NSM does even though there are slide deck that explains it but further. We might be something to refer to the documentation community meeting tomorrow. Yes, because I will be the first person to admit that a slide deck is not an answer. It is however apparently what I'm good at. Sure. So, what I can do is I can probably start a Google doc. If you're okay or added to that of our glossary and then probably can review it during the docs call. That would be super helpful. Because I've already done the preparation for the container world and I'll probably leverage the same. Having those slides out there is going to be super helpful. One of the things that I really enjoy is the degree to which there's a slide for almost everything out there already. You just have to find them. I think that this is a good introduction to the next topic. I prefer those long dark slides. Anyways, we have the metric project. You have the floor. Hey guys. So, I first have to apologize for the fact that like I haven't spent much time with NSM. You know, so just like what frame was mentioning, you know, so I pretty much like you know would be pointing people at the same set of questions like you know what you guys just made a note of. Definitely, like, you know, we would be very interested to learn about it. Now, just to give you guys an idea of what measure is so me and Lee, Lee Calcott, like you know have been pretty much like fans of history and like you know we have had given workshops like you know like at four events last year. So some of the most common questions that kept coming up were like you know why why a service mesh, which is obviously like an answer pretty well. Now the next question keeps coming up as to why this service mesh asked to that and like you know what's the overhead that it keeps bringing up like you know what are the performance. You know I mean like nothing comes for free like people understand that very well. Some of the immediate questions that keep coming up are like, so you know what's the overhead of, you know, bringing in Istio, what's the overhead of bringing link or D like you know and they also get into some specifics. So what we did was like you know me and Lee started working on this project like you know just like you know a few months back. And we thought it'll actually be a nice community project so we actually created this measuring thing. And now we also have weekly meetings I've posted a link to that like you know of course like you guys are actually seeing at the site like you know which is fantastic. So, we have a few contributors now just to give a idea of what measure is like so so measuring tries to address or helps, you know, or is trying to help address some of these overhead concerns like in which people have been bringing up. And at the moment like you can see there's not much because again like everything is pre alpha now one of the first things we did was we started off with like you know a simple proof of concept like you know which turned out to be a monolith and then like you know we started bringing it out into. You know, I wouldn't call it like you know pure microsoas architecture but then like you know into its own competence, and we thought, rather than having the adapters, you know, so I'm really sorry so. When we started we actually started it off as a project for a steel and then we thought hey you know what this is a sensible question that needs to be addressed across measures. So what we did was like you know we thought measuring could be a thing which interfaces with this concept of adapters, which again like you know is you can say I, you know I borrowed the terminology from a steel. But essentially what it is is that measuring itself it does not talk to any meshes any so as meshes. So what we did was we created this concept called measuring adapters. We are planning to have one adapter for every type of mesh and you can see it there like you know there was one for Istio there's one for link or D octane is still being developed and there is like a skeleton one for console connect. So essentially the plan is that like you know all these measures will actually have adapters and measure will actually interface with them. Now why should measuring which is supposedly a performance tool at this point in time like you know have to interface with these measures. So to partly answer the question is actually to essentially we have this concept of a playground in measuring where people can actually connect to these measures through the adapters and perform operations on the mesh. So say for example like you know they can actually make some changes to some configurations of Istio and like you know try out like you know some testing tools like you know to see if you know it performs well. So you know as you can see like you know this is kind of like you know where the project is it's it's I wouldn't call it beta like you know I would say it's pre alpha between like three months roughly like you know we started this project. And now we try to come up with this weekly meeting which is at 2pm central on Fridays. So if you guys are available like you know please feel free to join and also there's a slack channel. You know I have a link to that like you know and you will be in the slack channel. All the code is open source like and everything is under the layer 5 IO org on GitHub. So again like you know right now I am one of the main contributors to the project like you know just reason why like I'm here to actually talk about it. So one of the things that recently happened was like you know Lee got to know about this NSM network service mesh and like you know he thought it'll be nice actually for you guys to also have an adapter there. But like I said like you know I don't I'm I'm not I'm not in a position to actually recommend this and that for the adapter because you know I'm you know I I don't have much of knowledge about NSM. Which I you know I mean after attending this call like you know I'm definitely intrigued to actually learn more. I mean it's not that like you know I wasn't intrigued earlier and by the way I'm also one of the Twitter followers of NSM now so you know I'm definitely intrigued. I'm very intrigued to actually know more about NSM and so hopefully you know the hope from our from our measure project is actually that like if you guys can actually you know start off with adapter for NSM. And and you know get going this way like you know it'll be great to actually have you guys part of my show as well. And of course like you know so. I'm actually super cool really quickly like there was one I wanted to sort of point to this thing and we've seen it brought it up. We were just chasing down something right now a network service mesh where could you switch to the tab on the. Yep. This was a related to a bug and Ilya had gone through and done this sort of graph of latent setup latency for a request versus number of requests that have been made. And as you can see we've got a place where we're trying to figure out why something is monatomically increasing because that's not good. You know so but would this be the kind of thing like request latency that you can see being measured with misery. Absolutely. Absolutely. So yeah so I mean eventually like you know we want to actually make misery in a way that like you know it will allow you to actually perform a wide variety of tests. But today like I mean like I said like you know we just started like you know working on this misery project is pretty new so to start with like you know we actually have a very basic load generator. But I mean out of the box today you will be able to actually see that we are I mean like you know with respect to the technology stack like you know I'm a fan of go you know from Google. So pretty much like in all the back end and the adapters at the moment are actually all written in go but the adapters don't have to be written and go like you know because you can see that the connection is over gRPC so you know so you are free to actually write it in any language. But the main misery app itself is actually again written in go and for the UI we are actually using next years which is again like you know framework on top of react. So that's the technology stack and at the moment like you know we have a close dependency on Kubernetes like which we will eventually be moving out because for example. When we spoke to a console folks like you know they actually said that you know they give us a percentage that like hey you know what you know only 30% like you know if the people they know are on Kubernetes. So the remaining 70 are not so you know so which is actually a definitely like you know a good thing for us to consider so we will eventually be moving away from like you know being specific to Kubernetes. But again you know the misery app itself does not have that binding it's mostly the adapters so you know as an adapter developer like you know the person will have complete independence as to the way they want it. Just that like you know I'll have you know we'll have to make some minor changes in the user interface to actually remove the tight dependence on Kubernetes but but yeah other than that you are free to actually try misery it is functional at this point in time. And yeah there was a Docker compose while there's a tiny script which we have created to make life easier if you want to give measure a try. So please feel free to actually give it a try and you know we would be very happy to actually hear your feedback. That's very cool. I mean the thing is I think you may have caught some of this earlier with network service mesh a very good first approximation is to imagine service mesh. And then imagine that the thing you want to move is a IP packet or an Ethernet frame instead of an HTTP request. That's a very good first approximation. And so my guess is with with possibly a minor amount of generalization this could be super good for also measuring some of these things for network service mesh. And it might even be something that could be incorporated into our CI over time, because we do want to make sure that we are keeping latencies low for setup that we're keeping packet latency to the system low that we're testing through put through the system and so forth. Because all all those things that are important to the people to folks in service mesh, they're going to be just as important in their analogs to people for network service mesh. Absolutely. That makes perfect sense yeah. Yeah. To to drive towards your point about not being tied to Kubernetes as well. And that actually ties in really well with our use case as well so we've designed the system so that like Kubernetes is our is our reference architecture at this point. And so, but we have an integration with with open daylight now, and we're, and the API was designed in such a way that any, anything that wants to create a network service and wants to hook it up to the one to expose their their service in a, in a more generic way is able to create a network for our API is an API is are all written with protobuf and exposed with your PC. So it's, it's very easy for us to, to, to work with things that are not that are not Kubernetes based. Something like this like the fact that you thought about it not being tied directly to Kubernetes and you're looking at pulling it out. So it can run as a standalone or in some or in some other system is is definitely is definitely valuable to us as well. So awesome. Awesome. That sounds perfect. I mean, obviously, like, you know, what you just said made sense. I mean, like, you know, to get started. Yeah. You know, it's easier to visit off of something that's pretty robust as of today. But yeah, it's good to move away. Yeah, totally, totally. Yeah, totally get that describes our progression. We're very much fellow travelers with you guys in that regard. So like, if you, if you go through our slides, we'll always be talking about the Kubernetes API server as our service registry. The truth is, the fundamental thing for us is a GRPC call to a service registry. We just happen to have added that to the API server because, damn, it just works. Exactly. A couple of minor suggestions that if you haven't joined us in the CNC of Slack, we have two channels that you'll be interested in. So one of them is the NSM channel, and there's a NSM dash dev channel. And so feel free to connect with us on Slack channels as well. And that's probably outside of this call, that's probably the easiest way to get a hold of us where we're very active in those mediums. Yeah. Awesome. Sounds good, guys. Yeah, yeah, totally. Like, great suggestion. Like, I will be joining the Slack. I'm, you know, a Slack user myself, like, and I'll say, yeah, absolutely. Like, I mean, I would slowly join the Slack. Yeah, cool. Yeah, and the, and I think, I think Lucina was sharing her screen. She pointed out the NSM, there's the invitation, if you're not on CNC of Slack, the invitation is in the header of the meeting notes. So just go through that and you'll find it. Also available on the community tab on the network service mesh IO website. So, lots of places to get. So come, so come join us there and we will, we will help you with the, with the details, or you can ask us to do it and we'll stick it on our, on our agenda to, to get to it. Also gracious friend was mentioning, if you want to know more about the adapter and the audio feel free to ping me I'm more than happy to help you out on the information. Awesome. That was a prem. Yeah, yeah. Yeah. Awesome. Yeah. Thanks a lot for you. Yeah. And thanks a lot. Nice. So, so you wanted Go ahead. You're about to go there. Yeah, I was going to move on to the, to the logo. Yeah. Okay. Okay, so we have Moving to the logo. I was Do we want to, I mean this friend this be what are we discussed, but was wondering should we probably look at sort of starting and hack it on what are we discussing. Yeah, but that's Let's get on. I'm sorry, meet up. Yeah, let's get to the logo first. And we can, we can discuss this afterwards. Definitely. So what is the delay? Is this the latest one that we have. Um, oh, can you, can you be okay. Yes, great. And that's the second latest I'll I sent another one yesterday. Did I see the wrong link in there. Please feel free to correct the link in the meeting that it's if you if you would. Oh, yeah. Sorry about that. That was that was the second last one I will send the link. I was copying and pasting quickly and so I probably Oh, okay. Oh, no worries. No worries. Let me just grab it. Sorry. It's another I could share my screen, but no, it's probably better if I just send you the link. Just drop it in the chat that we can get it corrected and that way everybody has it. Sorry about that. I'm just trying to find it in my Million things. Okay, got it. I have it now. Okay, so I will put it in the chat. Okay, there it is in the chat. That will be the link to the newest one. I just got it last night. So some of you might not have seen it. Okay. So, okay. There seems to be great affection for sort of the three dimensional. No, people like them a lot like we've had a lot of people talking about like Row one column row one column. I'm sorry, row two column two people really like the gradient there. We have people comment on row four column one row four column one people really liking the sort of heptagon inside the buckyball. And I think that we also have a super interesting comment there where someone was like, yes, it would be great if we could get heptagonal faces on the on the buckyball and and I'm sort of like thinking through my my platonic solids going, do we have one that has the title faces. It would be cool if we did, but I'm not sure. So one other thing what I wanted to probably bring up is if the lines are thin, then when we want to probably put it in different places when it's small when it's large. So not sure whether they will be quite fitting it together. So just wondering should, I mean, whatever we select probably we may need to increase the width of those line. I mean, I absolutely definitely think we should see them at different sizes. I'm pretty sure that most of you have better capacity cognitively to shrink this down to a smaller size in your head than I do it's the sort of one of the very stereotypical visual processing things that I'm just terrible at. So, well, the only thing that concerns me with the with the two line one versus the three line one. Like, I think the two line one definitely looks better. The only thing that concerns me is when I talk with people and I say we need to think of network service mesh think of it as a mesh of network services. So, in other words, but like the network service in quotes, because service mesh itself is a has a defined meaning and a lot of people. So, so the only thing that that concerns me is, is that some people may get confused with thinking that it's network and then open quotes service mesh quote quote. So, differentiating the in terms of the text sorry sorry I might have misinterpreted completely. Yeah, so is. So I don't know. I don't know a good way to do. Oh, on one line. That's what you meant right putting. Yeah, that's, that's my, that's my, my, my one concern is in how people parse it because usually, I was used like quote network service like a mesh of network services rather than a service mesh that has a looking from. Yeah. Oh yeah. That should be really easy to fix. Yeah. But it is actually super helpful to have like different possible placements and fonts to look at it with all of these as well. Definitely so maybe I should. I'll do another board obviously and I think that I mentioned in the email thread that I would you tried some other colors to I've been just using blue and green, because it's just easy to design quickly with the same color so maybe I'll try some other colors and I'll focus based just on the the ones that were selected I think in the thread so far were row to column one. That was one of them and then row to come to right those two I think and then row for column one is that correct. This one. Yeah, so those three were the ones that I the only ones I saw selected yet but if obviously if there's any others. So, so I'll just focus on those three and then make the line sticker make sure that the text is as we spoke about and then try some other colors is that and then I'll make them. I'll show them at small scale as well. Thank you. That would be super helpful. So I will drop that back in the Google group in about a day or two is that that works. Thank you. Okay, this is absolutely fantastic. I'm really happy with where it's going. So, thanks. Shall we put some deadline here to I mean for us to to select not not for you Alex but for us to kind of convert on something because yeah. I think I think we are converging which is good and I like to think about the lines in terms of pragmatic things possible. I think what we'd really like to be able to do is have stickers at cube con and put together quickly, sort of a slide template for cube com that we can use with the new branding. Yeah, that's a much. How much time do we need to for lead up to make stickers. Yeah, we should be. Okay, cool. It'd be unfortunate if we finished and did all this work and finished it up. And then it was like, okay, where we missed the time. It takes to print. Well, we will order them in Barcelona. They will bring it straight to the conference. Perfect. Other links funding communities I am notorious for being involved with things that come in late in terms of printing. And so I probably know exactly all the people who know exactly how late we can get away with. So, I think we're good and I think I said I think we're converging pretty quickly so hopefully this time next week we'll have something to finalize. Okay, you keep participating in the conversation on the mailing list. You know from the results we've gotten that seems to be working super well. Okay. Cool. Okay, next is Bart. Is adding things. Okay. Can you can you quickly tell us about your, your thoughts and ideas. Hi, everyone. The first thing is, I would like to introduce myself because I'm a new to the project. And I'm Bart and I'm working for VMware. On a daily basis. I'm the part of the Kubernetes team, but I have some free time and I decided that I like the project and I would like to be involved with more. So, I, so far I tried and I'm trying still trying to help with CI CD and during the period of time. I saw that one of the things which is needed to the CI certification is the cold style best practices. And I think that especially from my expertise. After this initial period of time where we are doing everything fast and a lot of features, etc. It's always good to have kind of stabilization in a way of this style guide of the code. So, I would like to propose to create a kind of document and I would like to be kind of, I can be the owner of it to moderate that kind of discussion about the code style guide of the document which will help, for example, to do proper code reviews and to point the people. If there would be something maybe not easy to explain to the exactly place in the document where where are our generic rules about the cold style guide. This is my proposal so far, so I'm open to suggestions and I would like to maybe not connected to the any current proper release schedule but to have it in mind to create it as a kind of separate from the release process issue. We see here plus on from it already. I mean, I don't think that there's anyone who would minus one such such a proposal. My question would be, are there any tools that can help us in that like to check these things for us because, okay, you said that we can leverage this during the reviews we can point out to it and say, okay, I agree that this is the this is going to work like this, etc, etc, but it would be always much more helpful if there is some automation that can actually. So the problem is, I think that go is very opinionated and it is much easier to maybe differently. We don't have to create a document for the things which go already solves via go format or something but there are places which are not covered that much and I'm mostly thinking to put inside this document the things which can't be easily automated by a tools. I don't have any like a proper tools in mind right now. I'm mostly thinking about, as I said, the things which are not that easy to find without, I don't know, dynamic checkers, etc. Yeah, so I mean the one thing I actually do tend to feel it's good to get people guidance on code styles, but the things that might my experience universally is things like that which if they're not being checked by CI, they end up not actually being followed. And so it's just super super hard to code review as a human for style guy violations. And I agree and I think that even the conversation about it is really valuable to have like a one place, for example, you have issue or the document where we can discuss that kind of thing because I don't have a special kind of automation tool in mind right now, but this is a good opportunity to do a research for that. If there will be a, for example, places which we want to include in that kind of document to then find a proper tools which can help with that. By the way, we already have such tool or at least that it covers part of that we have a goal in check in our CI so but we just have to leverage the output of that. Yeah, I mean, we definitely have done some of the easier go has much better tools than most things for this and we have some things like, I mean, I'm sure all of us have been beaten up by shell check. It is a super pedantic style guy. God bless them they literally give you an enumerated error code that you can Google that will tell you exactly why it's unhappy with you. It's the best thing I've ever seen for linting in that regard ever. Yeah, that's true. So, so we're definitely open to that because good consistent things I mean we already also run Yama lint, which apparently I'm constitutionally incapable of getting right the first time. So, that the proper approach to the proper the suggested approach here at least on my side would be to just create the issue starts us back type of doc and let's let's move the discussion there and then we'll see where that ends. Yeah, exactly that was my point. I would like to create a kind of issue and this this like kind of proposal was to to hear the opinions etc. Okay, do we have any opinions? Yeah, let's let's get a proposal out there and see what makes sense. Okay. So we should probably get to the release before we run out of time. Yes, yes, yes, yes, yes, yes. Yeah, so the first point here is that we obviously missed the deadline for branching for creating the branch last week. We had some back and forth within the CI enabling disabling parts of it. And I believe that we are kind of getting where we want to be, or at least we have PRs lined up to to get us there. So my proposal would be to essentially branch by the end of the week and probably do the talk next week, which you will kind of move, move our deadlines with with the week or something like that. So, so I mean I want to get a quick sense of things, because my personal sense is that I would rather get a good solid release out the week after cube con than shaky release out the week before. Now that that that's sort of my my top priority concern that said, I would really like to get a release out before cube con. So that would be my secondary priority there. Does that sort of match other people's feelings and opinions. I think it would be a good PR if we managed to get it there but I totally agree with you that instead of just going and claiming a release without really being sure about it. It's not not really not really good. It's probably also we could have a branch for demonstration purpose. So at least for demonstration. All is fine and working properly without somebody merged something. Yeah, I mean, that said it would be nice to get some CI and CI in place for some of the demonstrations as well, just so they don't get in a broken. I don't want to occasionally get amused because I'll go to stand up the demo because I want to go down to somebody and discover the demo is broken, even though all the under functionality is working beautifully because I've got the integration test through it. And it's just silly things like Oh, the fix for the namespace move which was a really good idea didn't quite make it into the health chart that kind of stupid things. Yeah. So that's actually where Bart started I mean with adding home. I'm deployment into the CI to actually somehow verify and my ability of this. Yeah, Bart. Actually, with that, it's almost finished, but it's the kind of discussion about style guide, etc. was because I faced few problems related to especially needle pointer the references in like a power or five places, which made like kind of race condition in so so you had to specifically have an order which which resource Kubernetes resources were being created. So it wasn't that easy to just create a job and make it tested. So that's, that's because of the of this it's not finished yet, but it's like 90%, I think. I mean, I mean that we are we are on track there I mean like we are moving in that direction we have a plan we have someone working on it. So once this is kind of stable and in then, yeah. But otherwise, yeah, I do I do agree that that maybe even even just having a branch where we keep things kind of stable ish even without really releasing it can still be still be a better approach. Yeah, I mean, it really comes down to what do we want for a branching model. I tend to personally really like the masters, you know master is where the development happens and then you pull a throttle to do bug fixing but the throttles aren't really going anywhere. Because that way master can mostly stay open most of the time, and you can really get the stable the throttle is really nice and stabilized. Okay, let's see what you mean. Then we don't need, I mean, in such model we don't need branches you just need tax. Yeah, no I mean dropping dropping tags on things that are super stable. I agree with that. But the problem with branches is that for at least some period of time you have to double. Yeah, yeah. Both super this both a super pain in the ass and it's also incredibly error prone. You just not good at it. I do apologize. I've got to drop a few minutes early. Feel free to continue. Okay, I think that that's we went kind of through the general approach for for this. I would still keep the idea of having the branch. Now that it is gone. Okay, you'll see. Yeah, it's hard to do there. Okay, Prem, do you want to share the last couple of minutes to talk about the meetup. So, I and Fred, we're discussing about having a meetup or getting started with a meetup. So the idea is essentially we will need to probably get a list of topics and then we can have it in different regions. I'm trying to see it's too early but I'm trying to see if we can get some sponsors. I'm also checking with Intel. But only thing is Intel would probably want it to be part of their already existing meetup. But yeah, I just want to probably talk about it or I want to know your thoughts on or the community's thoughts on this. The second thing is also what I was thinking was, at least if you can start exposing the API is like an API guide. So if someone wants to try it out, be it the CNF developers or anyone who wants to do an ENSM type of thing. I was thinking it would be good so that as part of the meetup we can also make it more interactive in terms of having hands on labs similar to what Fred does. So these are some of the thoughts I had regarding meetup. Yeah, so I think in the interest of time, one little bit of lead up time to this thing. So I think it should probably be held after you. Yeah, sounds good. Yeah, but just started the discussion so we can probably come back and then visit it later. Yeah, and I'm not expecting like a huge turnout at the beginning, but I think we can make it larger. And something we can do is we do have the option of pairing up with an existing CNCF group as well and asking if they'll co-host it. And that would drive a lot of traffic. Yep, yep. Can I suggest that we add this idea here in the list of events as a kind of to be done event? Yeah, I'm going to. Something that we, you know, recur every time to it and just go and just see where we are. Yep. Yeah, that'll work. Great. I think we're out of time as well. Is there any last set of announcements before we're done? Is that? Thank you everyone for attending and we will see you again next week at the same time. Enjoy your day. Bye-bye.