 Well, I'll go ahead and introduce this man. So hello, today is September the 11th, 2019. And this is the CNCF, SIG App Delivery Community Meeting. This is our first meeting, so we actually haven't decided who the host was going to be. So there is myself, Brian Lyles. And then there is Lei Zheng and Alice Whitebar. And we are the chairs for SIG App Delivery. So it's a follow along. The meeting notes have been posted in the Slack chat. But I will actually go one step further and share my screen for those of us who don't like to click links. Do, do, I'm just trying to find the right one. There it is. All right. So today, the good news is that we actually have an agenda. And let's get started with attendance slash stand up. Actually, I didn't write this down, so I wasn't quite sure what you wanted to do here. But let's go ahead and do that. Yeah, I think first of all, everybody should add themselves to the doc if you haven't done yet. The document is open for editing during the meeting. And my idea was that the people who are on the call should give them a very short time to introduce themselves where they're from, what they're expecting out of the meeting. Just really one sentence. I really make this quick, but I think it's the first meeting to get to know the people who joined in here quickly. And ideally, we just go down the list pretty quickly. Yeah, hi. I'm Lei Ihankomi-Hari. And I'm co-chair of the SIG App Delivery and I work for Arribaba regarding to clone native application management. So who's the next? Hi, I'm Santano. And I work at the NICERI at CloudStay game behalf. I'm sorry for the background noise. I might be having some issues. Hi, all. I'm Gauz Raskov. I work at the NICERI for security developer tooling bits in London at the moment. But I'm in 10 different places in the next three weeks. Sylvain from Docker. I work on the update team. And I'm just here as an observer. And I also am a co-maitainer on Synapse and Defl. Hello, I'm Brian Miles. I am a staff engineer at VMware. I run a developer experience group inside of our cloud native BU. And I'm also one of the co-chairs for KubeCon. So blame me that you didn't get accepted. Yeah, quickly from my side, Alice Ricebauer, I'm working for Dino Trace and also co-chair of this group and also working on cloud native application delivery topics along this observability. How are you doing? I'm Noah Collarman from RedHash Amia, I'm a team architect doing a lot of application delivery stuff for customers. Hi, I'm Alexis. I've just joined. I'm along with Michelle, one of the two TOC sponsors for this group. And I'm very, very pleased to see that we have a fully fledged group of chairs. We can run it. Thank you for joining. Thank you for putting yourselves forward. Thank you for getting elected. And let me know if you need anything to help. I'm able to set up all of these meetings. But if you need anything, treat us as myself as Michelle, as the resources to get you stuff for the SIG to be functioning well. We are relying on you to make good decisions here. We're trying to delegate as much as we can of the TOC function to the SIG leads here. Thank you. All right. Anyone else? I see some other people. Yeah. Hey, guys, it's Mark Chilvers. I'm from Verizon. I work in the cloud engineering team basically we manage the Kubernetes platform on behalf of a large number of application teams within Verizon. One of the things that we're kind of looking to improve is how we can more rapidly enable cloud native application development. So hence my keen interest in this SIG. And hi, I'm Dave Forjack. I work at a little startup in Cleveland, Ohio. And I'm just really interested in this space. So I wanted to see if I could help out. Thank you. Thanks a lot. OK. Move on to the next agenda point. I'd say unless somebody wants to produce them. Obviously, for free to. I think we have nothing on other six this time. So I think we can skip over this agenda item for the time being. KubeCon. Yeah, since I was in contact with the CNCF team here, very brief update. Nancy is out of office this week. But the plan is that we're going to have ideally two workshop sessions at KubeCon where we introduce the SIG to the broader Kubernetes and cloud native community and the other one being a working session. So agendas have not been fixed and not finally confirmed. But this is supposed to happen over the next two weeks. And as soon as we have more details, we'll obviously share it with the group. So if you're going to KubeCon, you can expect us to meet there at least once, ideally twice. And more to come here. So I'll follow up with all the mailing lists as soon as we have more details for the next meeting. And just a side update. I believe Nancy's back tomorrow or today. Yeah. So keep everything. Yeah, she's usually very quick in replying. OK. Yeah. You can follow up with Nancy with the schedule of the meeting, right? OK. The announcement block would be the next one of the SIG. I think we don't have Amy here. And I haven't actually seen the announcement block yet. Did anyone else see it? Not yet. So Alexis, I assume this is something to just get in touch with Amy directly then. If you want me to do anything, that's great. I'm happy to do it. You need to just send me an email. Yeah. Just tell me what to do. And that's for anybody on the school. Just send me instructions. Please do X, and I'll do it. So I propose to make this the least effort for you. So I'll reach out to Amy, and in case anything comes up, we can then involve you if needed. Techleads next action item. So on the Techleads side, we have chairs. Right now we don't have Techleads yet. I think it's an open discussion whether we need Techleads. I think it's just for everybody on the call to really then involve themselves in the activities and as we need to see the need for Techleads. I think we're more than open to appoint them as needed. I think, first of all, we need to get into working mode and work on specific topics first and then move forward there unless somebody thinks they already see the need as of today for Techlead for the group. Yeah, I agree with what you said. I think, like, if once we're doing things, things like that might emerge. If they do, let's do it then. We've got several chairs, I think, otherwise we risk spending all of our time building a hierarchy. Yeah, let's build a big organization here that we don't do that. No, and I agree. We still have not. The scope for this SIG is still pretty large and we're still trying to figure out what the tackle first. So, yeah, it's not the time. I can say a few words about that. I think that one of the... I think there are a few areas where we can make rapid progress. I think one of them was there was a landscape and taxonomy task, which was to take the work that Gareth began, which is now the sort of humongous Gareth Brian giant spreadsheet of everything. And make some sense of that shit so that people can talk about it together without meaning different things. I think there was also a proposal from the chairs, or at least Alois and from Li Zhang, to sort of come up with some kind of app delivery thesis. I think Brian, you were coming late to that thread on email, but I'm not sure if... So I'm not sure if you agree with what they wanted to do, but something in that area. And then the other areas, I think there's a re-useful and low cost to set up a couple of working groups for subsidiary activities where there are small groups of people who are very, very passionate about a particular thing, which needs to be kind of deferred. So I'm thinking here about the serverless working group. And also I think there is an opportunity, if you wanna take it, it's up to you to create a PAS working group, because there are some people who are incredibly excited about PAS and they can go talk about that for a little while. But I think the main tasks are the landscape and also sort of definition of what is that delivery. And I just wanna stress those are suggestions, which you should, by all means, overall override change edit as you see fit. Yeah, I think the, yeah, sorry. Sorry, no, there's no landscape yet. It's all in the document. Yeah. Yeah. So I think that's pretty much in line with what we had in there. Anyways, I think it brings us to the activities piece. Just so for today, I really see there'll be just high level talk about the activities. Come up with a couple of action items for the next meeting and some people are moving sort of things forward. And for the other chairs, please add to my overview here. But we have in there is the clarification of terminology and Harry started the document here. I think this is step number zero before moving into the landscape because key will be for us to identify what do we actually want to have in the landscape there? Like how do we define application? Which tooling, which capabilities do we want to have in there? Which then leads us to the landscape. And I think that the document from Gareth and Brian is a great starting point there. And then maybe, Harry, you can walk us through that document that you started there. Yeah, yeah, of course. And then it goes further down there, like the maturity map of app delivery, like Github maturity, I think that's in the follow-up step. What I put in there is the end user survey. And the idea here actually is we should ask people where they would need most help right now. So I see that this is also contributing to what people are struggling with the most. So we can ask them, is your biggest problem delivery? Is it application definition? Is it rollout processes? Is it operations? Is it monitoring? So come up with more or less a questionnaire where people see where the biggest gaps are in what they need, which I then hope also drives more of the upcoming activities as well. And ideally, this is something we can put together also rather quickly and could be something that using the CNCF, we send out to a wide audience to get an understanding of what priorities of, especially the end users are right now. One proposal I put in there, which I think is much further out at some point once we have the landscape of tools, is to have something like a testbed where people can easily spin up an application delivery testbed and most people seeing different tools, different open source projects that they want to put together. I put in here the example of something that Red Hat did where they have like their open innovation lab stack and just click the tools that you want for certain areas and kind of start interconnect them. So that's what we have in there. I think the next question would be if you see it on an obviously divide paper on an application delivery, do you see something that's missing from the people here or something that you want to see us being addressed as well that's not handled in here? I think that the discussion of white papers that I think is interesting, mainly just down to some of the language from the agenda that just caught my eye. The idea of it being like white paper singular and it being on a fixed cadence, rather than necessarily being white papers that are around a specific topic. I'm not sure if other people have like strong opinions there. So Gareth, are you even thinking more like not a white paper directly, but something like a state of, I don't know, cloud native delivery type of report more than an actual white paper? More that I think, so I think the right area is as part, I think basically off the back of the, like kicking off the landscape work. I think what we'll find is that some areas that are easy to define and the things in there are relatively easy to put in that box and that there is some level of maturity in that space. And there'll be other areas where it's basically a very much a wild west environment. And like some of those might make sense earlier at already different times to have a specific white paper around. So an example might, I'm not saying this is definitely the room to do or even the one to do, but maybe continuous integration tools for Kubernetes like something that specific or maybe something more general, like even continuous deployment as a space. White papers around topics might be easier than like it's times kid. I think the risk of time-based ones is that we'll have some areas that we just have less confidence over that are more mature. And white papers feel like something that's more useful around something that has some level of maturity and that we can put some recommendation around. Super early stage things, white papers coming from CNCF, risk being everyone just trying to get their thing mentioned and we get into that big list problem that the sort of previous things had. So are you saying that instead of the list we more focused on the functionality like EG when we talk about CI CD, not talking about the products that are in the space but more about what a good CI CD system entails? Oh, no, I think like in some cases we'll be able to talk about the product in that space more that I think if we consider the taxonomy of application delivery as part of that sort of tiered work some of those areas will be more mature and they will lead themselves towards like quite complete white papers about that like what makes something good there plus these are the things in that space versus something that like a white paper about application delivery risks being either a book that goes out of day really quickly or just super high level. Yeah, I can see your point and maybe if you have more clarity in certain items and others it's helpful. I think it might also help us to break down maybe the people working on something into smaller working groups like if we for example think about like that the topic that Harry brought up around the application definition. So we could work maybe an application definition at the same time we could look at continuous delivery best practices we could look at CI or we could Exactly. Then look at security testing and break it down and eventually I think we will end up with a book. I think the point is about to do the chapters individually and wait for the full book to be finished. Yeah. And ideally it's not as long as a book. Yeah. And that's working on what those topics are like the like how do we break things down feels like the first stage. I think once we understand how once we've got a this seems a reasonable way to break it down. Some of those I think will feel really obvious at which point white papers around those topics might make. Yeah. And to Brian's comment on the landscape I think you made the comment Brian. Yeah. Everybody wants to get their own tool on it. And that's why sometimes people say like a landscape is not like super helpful. And I kind of agree what we can do in the group we can define for certain tools like a set of capabilities that you want the tool to have or not to have. Because everybody wants to like be on every possible box. And if you're in a CNCF landscape that's maybe the goal of your marketing team but it's not even more helpful to the user. I think you can also drive some of the direction like if you want to be continuous delivery tool you have to support like I don't know blue green deployments canary deployments these kind of things. You have to be able to work with application definitions and this and this way and you have to be able to do this. Obviously this will be longer discussions but I think this will be good discussions also with the tool providers. And then you would know that if it was in the landscape it provides a certain set of capabilities or might have a note it provides most of it but missing XYZ. So why don't might be controversial? I think it could be helpful to really move to move that space forward. Can I add something to this? Just stuff we've seen a lot of is a lot of people adopting Kubernetes are basically doing Greenfield apps but vast majority moving kind of legacy systems across and basically need to know how to take these systems and if they'll run on Kubernetes and what they need to look like to run them there. I think one of the things that could be really useful that this is kind of gone down that capabilities road which is basically what things do you need to consider for your application to move around to Kubernetes? Things like communication, service discovery, secrets all that type of stuff. We all have that stuff going but kind of giving a kind of a set of areas that you need to consider a set of points and then so that could be your definition of the app and then the supporting external tools would be your CI pipelines, your testing, your deployment, all that type of stuff. Do you know what I mean? Because we see a lot, we get a lot of kind of oh, we want to move this unbelievably VM based application onto Kubernetes and they don't realize how much work is involved. And there's like, once there's hundreds of questions but there's many, many areas to consider before moving across. I'm not talking about decomposing applications, right? That type of stuff, that's the bigger problem for everybody to solve. We're putting the kind of like, what is the core of an application and what does it plug into around into Kubernetes? Like once you have that, then it goes to advanced topics like, do you use things like, how do you deploy a helm or operators or whatever and you could give advice on that because we have two, I think people need advice kind of boundaries, not necessarily use Spinnaker or use Jenkins or use whatever. The tools will come out and the vendors are very good at marketing their tools and that one where it's capability is probably a better aspect to look at. So yeah, if I understand you correct, this is really how does your application delivery change from your traditional model to the Kubernetes model that we focus on this one as a transition over the application with some implications on the app. But like the whole monolith to microservices piece we deliberately leave out of this because- Absolutely, absolutely. If we're much wider and much more complicated space that we might not get in. Technically it's also not the scope of the working group so much. Yeah, absolutely. So it's about kind of defining what good looks like and how you kind of transition across that and kind of given points of view and aspects to consider rather and how to fast rules, do you know what I mean? Sure, there will be certain rules like the size of secrets and all that type of stuff but automatically it would be kind of just the general rules around it. And then once you have the application and what good looks like you go into the actual deployment and deliver each side of things and that could be capabilities as well. Because as you said earlier if everybody wants to be on the landscape for their marketing purposes I think that defeats the purpose nobody gets value out of it. It's capabilities are probably more important than the actual tools themselves. So that speaks to the second objective after the landscape which is the one that LZ proposed on the email list which is to have some sort of working sketch of what application delivery means in a collaborative setting without necessarily referring to particular technologies but talking about patterns and principles. Yeah. Okay, any other comments or things we are missing or that we will have an opinion on how we should address them? Okay. Then I would propose we use the remainder of the time maybe to jump into the document that Harry already started. Maybe Harry you can share and walk us through what you already did around the terminology doc. You think that's what gets us into working mode as that's the first piece that we have around. Yeah. Let me show my screen to talk a little bit about that. So I already started a draft talk about the terminologies in scope of the clonative application life cycle. So I think it's clear that the goal of this documentation is just like the step zero of all the activities we want to do. So we want to clearly define the terminologies in this field. And of course, what is in our scope but it's not. So there are several terminologies already at least here. For example, what is application or what is the application you're talking about in this SIG? So I just list several definitions here and it's very open for any review or comment so we can revise it to a perfect version. Maybe to just quickly jump in here what I think we put in the goal overall and what became clear to me during this meeting. I think we should define cloud native application delivery as by itself as well. So I'm just putting my personal opinion here pretty much but it would be good to have people look at what it all entails. So that we have a definition of what we're like on the bigger picture are working on. So for me that's again just my getting started opinion it's really from the time you have an artifact available to the way you deploy it, you test it, you secure the audits, you operate it, you run it and retire the application which is just a starting point. So feel free to, I think this document is also shared with people so that they can also comment on this one. I was gonna say, is this document shared? I haven't seen an animation of that. It might be, I think for things like this it's probably good to just over communicate in Slack to start with. Yeah, sure. And I've seen the channels too easy to miss too many things. Yeah, I think like ultimately getting things written down sounds like a good idea. Exactly, yeah. I think we need to, you know put the application delivery first as a first methodology or we can put it in the goals. For example, we don't want to actually include UI or anything related to local testing or local development in the SIG. So we will not explain that part but we will also explain what is the relationship between CI and the application delivery for example you can actually choose any kind of CI system. So all three do for a user to make the season but when we're talking about the CD part we are actually hoping that, you know there are some standard or, you know best practices collaborating in the SIG application for every part, so it's kind of like that cooperation relationship with the CI system. And we may also explain a little bit about what is CD, what's the relationship with CD and application delivery. So from my point of view, the SIG is actually talking about the specific technologies and the practices about continuous delivery. You don't have to use it but this will be more like a base practice. Yeah, for the terminology part besides the application delivery or the what is application delivery we actually need to explain something like what is application. And another thing I want to add here is the application instance because we are talking about a runtime concept here. For example, a Kubernetes deployment where Rappicus equals to three actually has three application instances. We want to make this concept clear because in the rest of the explanation we will actually use these terms to describe a application delivery project. For example, when we talk about Flagger when we talk about the Flux we will say this actually focuses on application instances or it focuses on application level or it focuses on the two levels. And another thing I want to explain a little bit is application versus workloads because this is actually to be confusing for many people. I think we already know that application is just a connection of the configuration but what's actually what the currently Kubernetes SIG apps is covering is more like the mechanism from the platform to operate application instances automatically. So it's something like Kubernetes deployment as Dave will say it, they are all workloads. And the Kubernetes operator is just another kind of workload which is written by user itself. So I think we need to make a clear boundary between application and workloads because there's a lot of actually a lot of projects which I think they are working on the workloads but sometimes they claim themselves that they're working on applications and we want to maybe fix this confusion in the future. And for platform I'm talking about the runtime layer to provide various ability to run application. In most cases it could be Kubernetes but I think we don't want to restrict the application delivery to Kubernetes only. So if users trying to apply the application delivery model to function and service or Fargate or Clorone and anything which can run container, I think it's fine. So after we have some, you know, the terminologies I will also introduce the model here which actually explains the phases in the donated application lifecycle which actually inspired a lot from a lot is this previous email talking about the lifecycle application delivery. So it's like from application definition to application deployment rolled to application automation operation and at last to the platform. And the first three part will be the main concerns of this application seek application delivery while the application automation operation which focused on application instances which is now more focused by the Kubernetes seek apps. So you can see how this two seeks corporate data and for the platform concerns and not the concerns of the seek but we will also cooperate with the platform concerns like we'll cooperate with Kubernetes we'll cooperate with anything which can run the applications. And this image is actually editable in these slides. So if you have any stress chains or any comments just you can just edit the picture there. So this documentation not fully complete yet because maybe we think maybe we will add more terminologies here and as a law is just mentioned that we want to have a very clear definition for the clonative app delivery at the bill. Yeah, so this is pretty much about this documentation. I believe this documentation should be finished after the next meeting because this is the very quick work and this is the start of all the other activities so we want to reach equipment on this documentation very quickly. Yeah. Can I ask, could you say the application or app? I assume that's a well, you're assuming that's a well-built application. Nice. Sorry, what do you mean by that? Sorry, so for example, let's say things like we see, what I've seen is basically people logging to files and are trying to log to files in container as opposed to just to standard out. So the actual application functionality itself that is that will work that will make it work well in Kubernetes. So if they're doing things like Prometheus scraping or all that, so using the functions that the platform provides, is that in scope or is that out of scope? I think it is in scope, but it is not part of the definition of the application. Right. So the configuration for the platform or for the ability of the platform, it is actually part of the application. Mentally, yeah. What I mean is basically, so if you take an app, let's say, I'll give you links to have a Spring Boot app and they want to load in secrets or configs, right? So there'll be different ways they can load that in as such depending on Spring Boot, but that's part of the application. The platform will provide secrets and configs, not necessarily, it's obviously the application to consume it as such. So are we at the secrets or config level, or are we at the application consuming it? I think it's... So I think it's... You're raising this up one thing, but we really want to get down to understand Harry correctly, and although my intention was, how do you actually define a Kubernetes application? And I think for a application, everything is to run... Somebody's creating a lot of background noise from there. Meet yourself. So that's it. So basically have a number of microservices, all the configuration that's needed, like databases, secrets, all of these things. And how do I define like this whole thing as a unit together? Like what's the way to actually define this? Obviously you can have a YAML file for my... I can have the YAML file for my service definitions. I have my CRDs. I have obviously my secrets and all of this, but how is like the whole thing defined as a whole? That's also why I think you eventually ended up with health charts here. So my proposal would be that all the people on the call add in anything they want to see, or that they usually define as part of the application. I think secrets and stuff is a good point there. I think we were starting maybe a bit more from a superficial perspective is, how can I even say that like five services belong together and everybody else understands what I want to do here. Which obviously goes beyond that and then you have external dependencies that you might want to map in there. So Link Steps, one would really be here. What do we want to define as part of an application? And then we see which technologies provide which, because in the secrets point is a good one here, here on top of everything else that we need. Yeah. Yeah, I agree with all of this here. The configuration of your dependencies or whatever you need to run an application is thankfully belonging to the definition of application. Well, the concrete unit of the dependency itself, for example, the MyC2 or the secret itself, it's not in scope of application, but the configuration for that is actually belonging to the application. Yeah, pretty much I think about the application and hopefully we'll see you next. Next slide. But that could be that. I think that's a good action. I would really define what we want to define as part of, of an application definition. And as people have done this in the past, I think a lot of people have an opinion and experience that they can share. Yeah. That area plus somebody agreeing on what we will define as a delivery. All right, it sounds good. So, Harry, how long do you, I mean, I know this is document is brand new. How long, how long are we going to sit on this? What, what is the, what is the next action item after we finish this document? Yeah. So the next action about this documentation is we'll, we'll try to open the review for the whole community. I think we will, we'd love to stand out to the link to the committee members to comment and review the documentation. And then we will finish the terminology part as soon as possible. So we just want to include very essential concept in this documentation. We don't want to expand everything and just make sure that in the next steps, like when we are working on landscape, and when we are working on any kinds of artifacts or deliverables from the CIC, we will focus on the same page here. So when we're talking about, for example, when talking about applications, we know, okay, we're talking about the group of configurations here. So that is the main purpose of the documentation. It should be finished very quick. All right. That sounds, that sounds great. Yeah. Well, I guess what we'll probably do is, um, I mean, I know we did it in the Slack, but it also should go out to the mailing list as well. And just, just so people know what's going on. Yeah. So in the next meeting, I will expect we will stand out to the final version of the documentation for the CIC, to take a look and to review it. And if we agree that the already, um, you know, it's, it's, it's already state, so we can move to over next steps to do the landscape. And then of course, we can actually start to defy the categories of the, of the landscape, which I think is also very important for us to, you know, begin to create a landscape work. Hi guys. I just wanted to, um, to make a comment here that since we are kind of breaking ground, I think it would be helpful for us when we are talking about defining terminology and setting a scope for what we're doing, that maybe we provide also examples of what we consider to be in the range of the scope of the project and, and what might be outside of the range of the scope as well as when we consider terminology in terms of what does it take to deploy an application on Kubernetes. Um, you know, some examples of what do we consider in the, the range of the, of the types of things that we're going to be discussing, whether it be secrets or health charts or YAML files or whatever. Um, that perhaps maybe we give some specific examples just so that we can uh, fall out what's, what, what's in and what's out. I will expect that to be the main purpose of the landscape if you understand it correctly. I mean, for the detailed part, um, we will list, you know, for example, um, there will be part, there will be the item in the landscape like application packaging or application application packaging, and there will be also the category in landscape like definition and there will be examples of projects listed here. So which one is doing that, which one is doing this? I think that is the most likely purpose for landscape. If I understand, it is correct. Okay. I just, you know, I'm trying to prevent, uh, prevent this from, from enlarging its scope, right? So trying to draw clear boundaries around what it is we're trying to do. Yeah. Yeah. Yeah. And I think I like the idea of having an examples in there, like what things could look like. And I think if we do this thoroughly, we even have like more, almost our first white paper fall out of it. Uh, Oh yeah. Don't misunderstand me. Uh, I'm not trying to say that we show an example of, uh, what we consider good practice or bad practice, but simply if, if it helps to clarify the scope of what we're discussing, that we can say this item, for example, we're not going to include in this discussion or in, in terms of what we consider deploying an application. Um, simply to, to help set the clarity around the scope of, of what we're trying to do. Cause there's a lot of parts to deploying an application. I agree that we can actually add a concrete example, like YAML file in the documentation to explain what is this or what is that. It's actually make a lot of sense to do that. I believe that. Yeah. But, uh, I don't know. I haven't had to specific to, you know, focus on specific projects in the terminology. Oh yes. Of course. Just if, if there's a specific item that we're saying, Hey, this might be valid, but we're not going to discuss it in this context. Yeah. That we identify that so that people understand, Hey, we're just talking about this specific part of deploying to a cluster that we're not going to address. Um, you know, high availability or, or what we're going to be doing for backup or, or, you know, um, some sort of, uh, uh, disaster recovery, right? We're just talking about deploying the app and that's all I'm saying. If there's no good concrete example that helps define the scope, obviously I don't want, you know, don't put it in there. Yeah, it does make sense. And, uh, I think given that we have the next meeting in two weeks and we really want to make progress on this. I think that's really what we should be focusing on, like this application definition piece. Uh, they really have progress there and then, uh, for the next meeting still be like in a reasonable size group. I think we shouldn't take on too much work, uh, for the next two week. And that's, this is still vague enough. Uh, my proposal would be really focus our energy for the next two week on this one here. Unless anybody disagrees. I think it's a great start for a brand new group. Okay. We are almost at the end for today. So just to recap. We mainly focus on the application definition, what you want to be have in there or how it's supposed to work. Uh, move this piece forward. For the next meeting. I think we should be really good on this one. And really focus on this one for the next meeting. I've taken down some other notes. Um, I think the topic of moving a brownfield application over to Kubernetes is, is an important one. And I don't know, no matter whether you want to take like the first step, what we should be doing there and maybe have it ready for discussion. Well, next week. If you have time, I can show you something, something we use internally. I think we would have to, yeah, I think we'd have it for them. Yeah. Yeah, that's fine. That's why we have stuff that doesn't work in this open source, but I think it's a good way to see if it's relevant. Yeah. So, um, I definitely want to see it. I just see, I'm just conscious of time. We have three minutes. I want to give you the proper. Oh yeah. Sorry. Sorry. Sorry. All right. Yeah. Sure. Next time. Definitely. I can, I can take it through. And it's not a product. So don't, don't think it is. It's just a, it's a tool we use. Yeah. And Gareth would also be good for it. Yeah. Yeah. Yeah. Yeah. A spreadsheet that you did. So that everybody's at least up to date what you have been working on. Yeah. The spreadsheet is definitely letting more in time. And other people have been adding to it. It's been, it's public for all the people who were on the previous. Um, I've definition working group. Uh, Middle East. But it's very much out of date. A lot of the days Saturday. Um, I think it's a useful list at this point. None of the data is useful. Um, So like maintaining it, like, I definitely wouldn't recommend us maintaining that or necessarily using Google spreadsheet. So I think it's worth the conversation about how we, like how we maintain the data and try and like, slice and dice it. Um, I don't think a spreadsheet is the right long term answer. Yeah. And what's there right now is definitely a snapshot. Um, Happy to try and grab some time about what might make sense to. Yeah, that would be great. I think because it's, I think, um, As we're this definition phase, every existing input and every lesson learned is helpful here. Yeah. So I'll, uh, I'll jump into thoughts down and bring it to the agenda next time I can make the call. Um, So I unfortunately have to jump off right now because I have to jump right into another meeting. You have to sell two chairs there. So it will be well taken care of. Thanks everyone. Thank you. Thank you. All right. So we're, um, Moving on a list. I think we're about done here today. Um, I guess we will meet again in two weeks. On one day of the week is this Wednesday. At the same time. Um, but before everyone leaves, I would like to see lots of comments on this, uh, essentials of cloud native app stock, because I will have quite a few. Um, and because this is very important to at least get the words of what we're talking about. Correct. So, um, all your help will be appreciated. So with that, I think we're done. Um, thanks for showing up everybody and hope to see you next time. Thank you. Thanks guys.