 Hello. Hello everyone. Hello. Let's see how many people can make it today. I heard from some people, especially in the southern parts of the US that they are starting to get the power up and running again. Every past conflict today. The reminder to yourself to the meeting. And I think you're fine presenting today on Gimlet and one shot. Yes. By the way, it's hard to hear. I don't know what you're using the right mic. Could be. I'm not. Let me just check. It should be fine. I'm hearing you fine. Okay. Hi, if I turn up my wall, everything is fine. Sorry. No problem. Yeah, I was because I was messing around with my equipment and I'm okay. Yeah. Yeah. Thanks so much for a minute. So, yeah. Yeah, let's then maybe. What's the link in here again. Most got hurt from some people that they're going to watch their week. Today. I mean, you know that document already Thomas and Omar. I propose to from the agenda perspective to start with a small sick update. Sorry, so it's more working group updates, which will be short. We won't have the gift of circle today. Maybe again had some collisions today to join a meeting. She was just going to watch afterwards. And then I'll give a small update on potato heads because we also had some additional contributions there. And then we would jump into the talk about give that and one. That would be my proposal for today. Okay, we have some people joining in here. So feel obviously free to talk about our topics. I'll just drop the agenda. Unless you can't hear you. You can't hear me. No, no, again. Okay. Okay, I say let's kick it off with the operator working group I assume it's going to be a quick update from your side because you're in between a lot of work but I'll pass it over to either Thomas or Omar to give us an update. Currently there's not much. Nothing, nothing really new in the operator working group. Currently we are trying to make progress we are writing some some sections chapters and so on getting feedback. Yes, and yes we hope to get it done soon. Yes, and if someone likes would like to contribute in one or another way. Feel free to join the operator working groups like channel will also take a look on the GitHub issues and just contact us if you want to contribute. My proposal was the last call for contributions that followed some of it on slack and Twitter and almost felt that people said, I don't want to contribute to like that amount of work that you're already doing but I have this other tool which I'd like you to mention as well so like overall how well did this go and specific areas where you're looking for feedback I think that's usually the other confusion confusion that I noticed from people say okay yeah come with you think what exactly they want me to do. It would be especially it would be cool if someone could provide best practices and so on for the operators, because I think the whole world talks about best practices of operators but nobody writes about it. Exactly this in this area would be cool. And also, if someone would like to add some some products frameworks for operators, it would also be cool if they will mention, especially for what are they meant for and how they can help customers. We also changed the way we work we talked about it in the last meeting, and we feel that the structure that GitHub issues give us right now is better so is someone wanted to contribute in the past and felt that he doesn't know how to do it because Google Doc structure almost. Yeah, I think always breaking up it's just breaking up for you as well not just for me. No, it's also broke up for me. Oh okay so. What do you do now, I mean you're working with over so what did you change from a structure perspective. We did not screen change something since the last meeting, but a lot of issues regarding of tasks we need contributors for. I also want to mention is we got some new contributions for us from some frameworks as you build or, I think, hope. And they were also very, very helpful at the moment. Omar you're back. Yeah. I continue to talk and then I realize everything is stuck so I just wanted to say that if someone wanted to contribute in the past and the Google Doc was a hard place to do that. We now we feel that the new GitHub issues way is better and we think it's much easier to contribute we find ourselves easier so if someone thought about it in the past. It's more than think about it in the present also. Yeah, I think the more concrete you make the request for input I think the easier it is to get it. I mean just jumping ahead a bit of the contributions we had on the on on the potato head project. I just put in an issue there that literally read update the flux example to flux to. And actually, I actually jumped in here. And did it. So I think that they are being like very specific on on what you want so Alison jumped in she updated the example, I think they've been more specific the more it helps. And like that was really right it for customized or do it for this and that. So that's kind of my learning there is the more specific you are the more people are likely taking it on. I think that's what that's why I was asking where do you exactly do you need help, because I think that's where you're most likely. If we just have very wide our audience and like very wide range of things people could actually do. They have issues open for every section in the doctor still need content in it. I will pass another round on the issues verify that it's state exactly what the content we accepted, we expect to be there. But we have project and we have issues. So people just can say I'm working on that issue. Basically need content and that's hard to ask for people. It's not just my learning the more specific you are what you want to do the easiest to get from people. Yeah, I'll do another review on all the issues, making sure it's documented well. Yes, we could try to provide more more specific issues so not only right some right some sections about frameworks but for the specific framework and so on, because I think then the and the community is also mentioned. So hopefully they quickly jump in. So also from from what we did on around potato head when I was asking for help me example people from health jumping in for a cloud native application bundles the same thing happens to the more specifically you ask, the more likely this you get people to jump in and they then usually very open to help. And that's just the general guidance because otherwise people say yeah I'm doing something but I also picked like some top issues where people can contribute but I think we have like great examples of real world use cases and maybe even break the real world use cases like real world use cases for installations for automatic upgrades for whatever you wanted and then we can share it and use Twitter and other channels to to share it and maybe also I'll see the end user community because this is something I think we were we could engage the the CFN user community. That's, yeah, a lot of people in the user community could do this. Okay, thank you. Next topic before we jump to give that and a one chart. Potato head update so the potato head project that small tiny project that we started for initially the last cube con session, which we were doing. And newer contributions it now supports for meteors. We know that for me to support in there that goes also to it for telemetry support in there and we now have flux to support as well. So we see that people are continuously contributing to to the project. Right now I think the biggest challenges that as this was never planned to be a project. It's really about finding people who also test and validate examples so that after we had this discussion what, what kind of support would be needed like if somebody has a new example, just trying out different examples with different tools is definitely helpful. I usually trust people who built tools that their examples are going to work. But for me, like okay, I'm taking the example right now and I'm playing around with it and it starts to get easier and it motivates me even more that all the examples keep run being running on like a local Kubernetes environment. It still is a challenge it's almost this made that challenge in app delivery how do you test your app delivery is again automatically test whether something really works. Maybe I come up with an idea and how to solve this problem. So our outstanding topic there, where I again are not planning to make progress is to split it up into multiple services. I think that's where the fun really starts. And where we can add more. More more in there as well. I think I just need to put it into an issue and get the first version done. The good thing is that now everything builds automatically anyways all the images are created automatically that makes a lot of the updating simpler and again for the actual web service that we will eventually need. I'm still looking for somebody who has more web development know how than I do which means pretty much everybody on this planet except me. Where we can then dynamically assemble that the potato heads and just getting it done. I think the assembling and the other services can be done by not that much you are my knowledge but what they do have itself might be there. Yeah, and actually also as soon as we have a more stable maintain a structure so if we find people who really have interest in getting this demo application, or developing the demo application further the ideas and also to eventually just submit as a CNDF sandbox project so you just make it. It has a quite a number of contributors but from the maintainer perspective. I think that's where it would be great to have eventually other people stepping up or finding enough interest there that it's not yet submitted but I think it would be a good candidate for this type of like sandbox project. And with this I'd actually like to pass over. And because this is actually the perfect transition to last because that's how we got to know each other because he contributed actually to potato head. And for the gimlet and the example in there and that's actually great what he's doing so please join us here and present what you're doing there because I think it's like super interesting for people like you split it into two parts like the gimlet part and with the one. One chart chart. Yes, yeah, sure. Thanks for the invites really so yeah I just found the pot the pot Tato had app and I use it in one of my blog posts and then I made a contribution. That's that's how we met. And I don't know how much time I have I try to keep it short. And maybe I started one chart because it's a simpler concept and then just get into the basics of what gimlet is. Yeah, I think if you'd keep it to like 20 minutes including discussions that absolutely so I'm going to finish in 10 hopefully and then you just can talk. All right, I'm going to share my screen I hope you will see it. Yeah, so I'm last look for gosh, I am running my solo consulting firm cloud native stuff. And besides that I'm also putting a lot of time and effort into product development so right now it's a consulting firm with some product work, I like to flip that around if everything works out as I as I'd like it to. So there is this thing called one chart, which is a home chart. Basically, the title says it all or tries to sell it like one chart to rule them all. Basically it's a home chart for your application deployment because you can find a chart for all the infrastructure components out there. But when you start developing your own projects. It's, it's not easy to just copy and paste your YAML snippets together. So, over time I, I started this chart and whenever I came across a new come across a new use case, like I need to set an image that's a basic use case or but when I need to set an ingress, I just extend this chart and hopefully with like 20 or 30 use cases I can cover the typical application deployment needs. Just, just a quick intro. So, by default, it, if you use one chart one chart and you set the image and the version, it speaks out, you know, a deployment and the service so it's, it's almost like the help starter chart. And later on if you add more stuff in it, like environment variables, it's one step more convenient way to write this, this values file than writing the Kubernetes manifest. So, if you run this example, then you will get what you would expect. You have a values file, you have a config map created out of this values file. Right here the values I just provided, and this config map is referenced and everything from in it is pulled in. And you know if you want to specify an ingress, here is a quick way to do that. I'm always in trouble finding the indentation for the, for the ingress snippets so I'm like making like five mistakes before I get it right so I just put this into this, this chart. Basic things like or not basic things but for high availability if replicas is greater than two, I just by default put data, there are pod distribution budgets and some anti affinity rules. So it's basically if you get started, you have an image, you want to deploy it quickly. That's very convenient way to do that. And I found myself being very happy when when I'm at this stage and I want to deploy something it speed it up my workflow quite a few times. It's like a cron job version of it, like if you want to just run a cron job, finding that the ML and the Kubernetes docs page and assembling that snippet is more time than I would I would like to use for it. And as things progress, I will just add more use cases here, and it's on GitHub. So you can also add feature requests or pull requests. This is a very simple idea. Maybe you have questions to it already. Maybe not. I can proceed on how I use this little component in furthering my work. I actually have a question because okay, but it really piqued my interest is because I started to see a lot of people doing this right now like they don't keep writing over for your health charts. They left a lot in templating. A company who I'm working closely with. They said, well, also they don't want to teach everybody how to do kubernetes so their, their charts contain they also have like a reference template charts and people just put it in the container. And they kept extending it, they kept adding like service mesh configurations, they keep adding open rules and building more and more and more. And they actually know when somebody deploys something. And they know exactly what they're getting. So I think the first question is how extendable or more harm model or is this so that I could add like my open configuration my networking configuration in there. And maybe it's not with the first question because in the second one would be okay how much can I also create my templates because I was testing that you have like an API template a web server template database templates. So does this work so it would be my two questions here. Okay. Well, so that's the other side of the story. I, so I had this template in every projects I had, and whenever they have a new need, whether they want to mount an Asia storage bucket, or they want to just exclude the service from from link or the service mesh, I just have these simple flags, given to developers so instead of passing wiki items around and YAML snippets. I just tell them that hey in the latest version, there is this support so you can use that. So yes, I think this chart could be used as maybe a starting point for an internal chart. So obviously, this chart will not cover all the use cases of everybody. Because then it will be an un-maintainable spaghetti, like Helm charts get often this criticism. So I think I will just stop adding, let's say, when I reach 30 use cases, and that should cover like a basic OPA rules what's that open policy agent and so on. So, so I'd like to cover the basics and from then on, I think I have two recommendations for people one is to fork it, which I have a private fork of this one in the project I started recently. And the second one, if, if Helm becomes too annoying for you, you can always run Helm template on your latest chart, and you can just have the YAML and you can take it wherever you like it to your own templating solution. I had an internal chart in my previous work, I think I also had some talk about it, it's a project is amazing, especially the website. The examples are all clear and, and I think that even if I don't use the chart, I definitely want to use the website. Okay. But yeah, it's a great starting point to tell people as use cases around things around charts around how to do it. And I think, yeah, it's great. Thank you. Thank you. I put a lot of effort in the end of upside and it's really targeting like people who are new to Kubernetes and, and, and just want to get started and it's sometimes the explanations are very naive, but I try to keep it coherent at least. Yeah, I think it's a good starting point for people to think about how they want to structure their internal charts. Just like that potato head can give a good examples to have to do things, which is missing in the home chart. Yeah, if I may add one comment on this, I think this is a really good project. It's a good way to get started. And one of the charts that I try that we've been working on is to also have an option for you to provide a good URL and also build an image on the cluster, and then deploy it. I think this is probably like philosophically this is probably the same thing what you're doing, plus the whole build image step. You're both working on it. I'm probably going to do some self criticism on it because I would precise the same thing that we are doing also on it, which is, while it's a great thing that you provide these knobs. I think the challenge which I always face and also face in which I'd like to share with this, that sometimes we try to override the different workloads pick items on top of ham chart, and it becomes a challenge to know where to stop that for example, like replicas. It's there inside the deployment spec, but it's also there in my ham chart values. I think the challenges to figure out what is that good subset that we need to expose and what not to and I went for the docs I think you've done a pretty good job with it. Thank you. Yeah, it's going to be a balancing exercise and I think even at one company like a common shared chart will be good for 95% of all the teams but there will be always a unique team who just want to do their own thing and that's fine. They should just then maintain their fork, I guess. Right, I agree. All right, so this is actually a building block where people who are new to Kubernetes or just want to move fast can can use and I built some other tooling, which is building on this building on Helm chart in general, but I try to promote this this one chart approach, which is gimlet which is like a command line tool at the moment, and it is, it's basically get upstooling and tooling around Kubernetes to get started. So if you guys are fine with it, I'm just going to get into that and share the screen again. Yeah, I was curious about the name why you picked the name gimlet so I think it's a good ring to it. It's a bit arcane. I know it's the drink. It's not about the drink. So I am gimlet is also like a little carpentry tool like a little drill like a hand drill. And that's what I found like a great analogy like I'm building a tool and that's a nice little handy tool so that's sort of the analogy I would like to get across but I think everybody thinks about the drink and I just accepted it by now and I like it for the the ring to it like gimlet I just like how it sounds. All right, then I just get into gimlet just very shortly because I think it's larger thing or it eventually will be larger than just a 10 minute demo but I just get started. So, so Helm charts so I got a little bit bit overboard with with Tom charts and Tom charts has a values, Jason schema file, and and based on that, I made a little tool inside the gimlet CLI. Let me just navigate there, which is called chart configure. You may have seen this already, but so if I type gimlet chart configure one chart one chart. It actually opens a UI, and I generate this UI based on the values schema file values Jason schema. So if people are again new to Kubernetes, they can just come here and have a UI on their laptops. Set some readiness probes change the path to health Z. Maybe if they are savvy enough they can delay the health checks and basically if they close the browser, then they should have the values file. I did on their screen. So that's, that's basically the values file for one chart. And if I just go one step further, if I pipe this into Helm template one chart, one chart, and then give it as a standard input. Again, if I just do some changes. This time it's going to be for my value. And again, if I close this screen, then, you know, the values file was piped into the one chart. And the config map has this value. So my bar, my value. So sort of there is like a little workflow if people want to just work with Helm values files, they can, they can use this I think it's even able to get saved values file. So if I would have saved this values file, I could have feeding into this workflow again. And I can generate manifest like this. And with gimlet, I am a huge fan of GitOps. I think everybody is these days. But if you have a Helm template, I also wrote another little tool, which is gimlet GitOps. And then it basically writes into a local copy of a GitOps repository, following some conventions. So if you, if I maybe I just run this example shortly just let me just look into this GitOps repo I have here with the folder structure. So let me just look about the environments should be maybe production, the app should be my app and GitOps repo path should be GitOps. And I'm crossing fingers that I know my bash enough. I don't. I'm not misinterpreted here. So, so let me just break this up. Okay. So, let me just write the manifest to manifest.yaml. So this configuration bit replicas 10 close. Maybe I have some state issues here. One more time. Close it. Good. So now I have the manifest file bit replicas four. And if I gimlet GitOps write the manifest file to production app, my app and GitOps repo path is GitOps. Then I think it has written it to the GitOps folder structure that gimlet likes or promotes. There is like a little convention how to structure this. So that's basically gimlet GitOps write. It's a little handy tool that you can use from CI. So that's sort of the virtual idea behind it that some people likes to write their GitOps repo by hand, not having, for example, flux auto update the image. So in this case, you know, code change comes in. There is a CI testing process artifacts on and then you write stuff to the GitOps repo from where the GitOps controller is pulling down stuff. So this little CLI gimlet CLI is able to give you a set of conventions and a few tools like writing manifest to this structure deleting and also bootstrapping the GitOps cycle. So it has like a gimlet seal command to because one chart has support for sealed secrets. And, you know, a ceiling sealed secrets is kind of a pain in the S sorry just a pain. Meaning that you have to like a ceiling keys one by one and so on. So there's a little convenience feature. So the last thing I'd like to add that all this playing with values files is nice. With gimlet I also introduced a manifest file structure, which is very similar to all the helm release CRDs you have seen that are out there, flux or go CD everywhere. This is my own, which is the only difference is that you should keep this in with your application source code. So this is for developers. This is like a split workflow. So developers will be able to store their whole configuration in their source code repo. This is the values file file part. This is the chart reference and this is some additional meta information. gimlet has some tools to process these files render the manifests write them into the right place. So that's where gimlet is today. That's a CLI and mostly helping people who do stuff from their CI or from their laptop just to play around with their laptops. And right now I'm extending it with a server side component, which is basically detaching everything from CI. So it's not CI from where you write stuff anymore to the top repository. Instead, I introduced a server side component, which we are able to support. Policy based deploys like everything from master should go to production or some on demand stuff rollbacks and so on, without replaying the CI procedure, and perhaps introducing more access control as well. So that's just the future stuff I just put the concept down there in the blog post. So that was that it was quite a lot of things I think I think for now. What I wanted to convey is that one chart is is a very nice foundational building block or charts in that sense, which I build more stuff on top, how to generate manifests out of it, how to store them effectively. And then I also try to give people more workflows. So that's is going to be gimlet. So that's that. Thanks for listening. Yeah, I think that's pretty cool. So when I first saw it, okay, this is like really nice, especially like the UI and the configuration capabilities. So there is a bigger discussion on where your environment configuration should live and as you mentioned different tools of different opinions about where this should be. I think I was confusing me a bit because you called it a github's tool so I was assuming that there is a component that actually does the deployment. So you would have like influx or see in the in the RGCD type of environment. I mean, don't get me wrong, I think there's already a lot of components out that I can do exactly this and why invest in something that that already exists. I think that's just maybe a comment here. So when you told me if the github's tool I was expecting something different than what it actually is. I don't know how the other people think about it but it was just I think that the naming might be might be a bit misleading here, but what the tool is doing I think is great. Like helping to manage those components and so forth. I think it's, it's super helpful and useful. Because we have other people here as well. They can see the value so I'd like to get other people's touch on. It's used to work a lot on. We're going to need this deployment and also have to make them available for other people. I know that Thomas does, because we're probably working closely together so I'll make it up to other people now for questions. Anybody wants to maybe I just just a quick creation. I think it's a fair, fair, fair point. I should really find what am I really building? Is it a release manager? Is it some other thing? Maybe you guys have some ideas? How should I name it? But true, I don't have the actual github's control loop that synchronizes stuff between github and the cluster. I use flux for that because it's just that's a great job. I know how you would describe it if you really don't want to use the word github's but if you, I can't imagine other than the github's repo editor, which is really what you're doing, which is the left hand side of a full github CICD workflow. So, you know, I always find it tricky when people say it's not github's unless there's a deploy step. Okay, well that's probably true if you don't deploy something you're not really doing github's just editing static files somewhere. So, I think the interesting question to me is when you see this kind of stuff, what is the actual workflow for validating the changes before they actually get deployed? You're slamming into your get repo, you better be able to undo your changes and do all sorts of other things because right now it's all, the tool looks like it's just helping you edit quickly. So, if I had infinite speed fingers I could do that manually and I'd still have problems when I pushed to my repo with continuous deployment because I didn't validate anything. So the whole, I'm interested in these tools because they help you do things and not make errors, but then you still have to do them, I would say, in flight actively. So you have to see what happens when they fail deploy with these tools be used to undo your things, undo your good deeds in your repos. Those kinds of things are interesting to me because unless you actually have the edit part, the validation part and then the application which could fail and then you have to roll back and do all sorts of other stuff. You're solving one piece of the problem I guess. I really like what you said about the editor part because at this point the CLI is really just doing that. So, I think it's so. So once you do that you then start to grow, if you were growing this kind of capability you would say edit, then you need to validate stepped, which is the shift left of the linter that you would run on your manifest before you let Flux or Argo CD take it and deploy it. Because if you make a, you know, if you make an edit, if you're doing this by hand you make a typo your replicas to 4 million. Right when they arrive at your cluster perfectly good integer, arrive at your cluster they won't, there's none of resources to do that many so just sit there and pending state. Those kinds of things should be caught long before you actually push to the repo so if you have tools to edit should also have tools that validate, which is part of your CI for forget repos, forget ops repos, and then potentially even dynamic validation. So if you know where it's going, then you'd have to talk to your deployment facility to pull the rules like admissions control the rules or policy rules that you may or may not be violating. So you're at the beginning of a, of a pretty big piece of work where you can, you know, you just don't want, you want edit the edit capabilities to ensure that the structure doesn't, you know, you don't mess up your structure, because you're not going to do it manually just don't let someone go in and hammer the yaml you if you go through tools that's how you can sort of simplify that and, and then you can even have logging capabilities so you could keep track of who did it and what did it like you know you could grow this to be infinitely capable. So, I don't know where you want to take it but that's sort of it's an interesting. You know, a lot of these and yes, who I don't know who said it earlier. There's a lot of these tools as well. So people write, they start to get excited they write a bunch of tools to help them and then the question is how do you build an ecosystem around a tool that does the one thing really well plus the other tools that do their one things really well, and then flow into the universe of sort of get ops, which just has lots of pieces. Yeah, I think it's a good point. I think calling it an editor might be good as well as like the validation part because that was a hit too. At least they're having the ability to do a dry run on things. And then there are nice things that I'd see that that were usually struggling is okay I want to have this for another environment like I want to call an environment just build it but I want to modify just a couple of things like on a base repo. And maybe something else depending on how close you want to get to get when you at least commit something to get. Almost like having me get per se is version management. However, is this version management in a way that necessarily doesn't help me if there's a lots of pushes to a key three tool before a deploy. You'd like go back from version one to two version two it's built for source code. And if you look at all of the the providers out there you have like what is it they're called merge requests for pull requests and it's like bigger change sets. And if you have something like a change set management that will also be all cool, because that's what we often have to do, you know, want to like upgrade, upgrade, upgrade, upgrade. And they can want to like get like more or less my configuration risk between two environments. What in our unit we see. And again it is my problem unnecessarily yours that people keep continuously deploying to say they're deaf environment. Obviously the data can take latest as a whole and want to deploy to stage but they want just to take, okay, give me one change set. And what I mean is actually really just one change set of multiples. Hope it makes sense somehow. So you're saying your dev environment as has a cumulative set of pushes so hundreds of potential changes but you only want to subset of the, the three you really like. And they're not managed as a separate branch or a separate set. Is that correct. So we keep, we see a lot of people keep that open, more or less so that people can push and push in there. And it's, it's okay for the bigger repo, you might say well I'm taking like the updates on this service and I'm not taking the updates on the other service. Obviously this depends on how you structure you get repo. They were used to actually like the directory directory stage and the directories below the services. Yeah, I understand what you're doing. I'm not sure that's, I think it's an abuse of get some way. You know, if you want to developer to to are these dev environments shared then so they're constantly integrated. Yes, they're constantly integrated. So you have no hope but to share through that push common push. Right. Okay, that's, that's, that's your problem because the normal way you would do this if you had the resources is you'd fork your get ups repo you pointed at your own environment you push as many dev configurations as you like and then you submit a pull request with the final one up to your to your to your dev environment that's the shared one as opposed to your personal one. But if you're forced to share a CI integration environment and everyone's slapping their changes on but you just want to cherry pick some. You'd have to check them all out into a branch. And then send a pull request from that branch into your stage environment where you're just integrating those three and I suspect cherry picking those is kind of be tricky if you have hundreds. I mean, it can be done but it's, you don't see people that sit in if they go to like really extreme approach and they can replicate environments for each developer developer also for request constraints. I also kind of want to get into a point but as a well usually should not your deployment should not break other people's deployments. Yeah, but yeah, I agree. I think it's a matter of taste. I think it will be all trying to say I think it's a great tool and there's lots lots of other problems out there. Yeah, I think it's also good for, I think it's part of the work eventually for the github's working group and I really wanted to get this here because I think it can help a lot of people do a lot of things. For me, the number one thing it does it helps people to easier get started with the meters and getting something deployed like this whole idea which we have of making things simpler. I think one chart can be a great help and also, even that can be a great help but you have neither repo and then take now a tool and it's going there. And I also like the one thing that's, you have the small tools to do one thing well, I can remember this from this whole. From the whole web community, it may I think our industry is always evolving around we build a lot of small tools that we can plug together. Then we decide now that's not a good idea then we build one big tool and to end that gap does it all then we realize no that's not a big idea reader and then we go back and forth. Right right now I'm more in favor of let's let's build a couple of smaller tools and let people pick and choose what what they want because we all in this early learning phase. And things are revolving quickly so that's really what I like it's like they're not banging to everything I can use one chart, but I can use like totally different tooling for other things that think really cool with most projects that come out of the world. Okay, we have more let's use up the time today. I'm going to add already left, but I think we have people still here from also from from our girls if you if you haven't interacted with the other people yet, I would encourage you to so reach out to them. I mean it should work with our pretty much out of the box. It would even be a way to do it easier because you have a predefined gets to get three for structure. Which I think is great. And, yeah. I think we all do used to mailing list and to talk about topics to present for the next upcoming meeting. More about that was a good presentation. Thank you. Unless anybody has any questions left. I'm not kicking people out here. All right. Thank you. Thank you guys for the opportunity and also for the great feedback. I had a few. Thank you for presenting. Okay, thank you. Bye everyone.