 Test test coming through. Thank you. I'll give it a few more minutes before we get started in here Liz you made it Greetings having a little meeting and un-meeting issues there Perfectly fine. No worries. I'm just giving everyone a few more minutes to be able to come on in Hello everyone We have two Today We have two regrets today, right So sad Who was the other one James? Justin, I think it's perfectly fine We are not To my knowledge taking a vote in this meeting. So we should be fine on that. Thank you Should we get started? Yeah, I think we can grab a roll. All right. All right. Hello everyone welcome normal rules apply and you made it and Amy will update that's right tag updates this week We're doing them in alphabetical order All right, let's start with at delivery Yeah, hello everyone Quick update from tag at delivery on the project side crossplane is Already submitted and I think waiting for final approval from the TUC Depper is submitted as well for incubation I think they are right Don't know whether the interviews already happened on Depper, but the recommendation and due diligence from the Tag after the reside is done The captain project also presented for incubation in the sick, but it's waiting for To get the sponsor from from the TUC right now, but most of their work is done and they also waiting Who is the TUC's wants it for Depper? I'll let you know. I think it's Dems, but that might be wrong That's news to me Dennis Lee, sorry, it's Harry Lee sang Harry Harry's the sponsor. So he's were sponsoring another one So I was just it was a couple of projects that but we have you here. So it could verify that one Yeah, on the deliverable side the chaos engineering white paper is slowly moving Along here, we're also still working on the charter for the working group. So the team has started to work on that one Our demo approach it from the potato head project for showcasing all the app delivery projects within and beyond the CNCF Game now more momentum again So currently the project which used to be a single service which is only of limited value obviously to show distributed service updates Has now been kindly updated to distributed services and currently all the examples for all CNCF projects are getting updated as well This also helps the work which we are then doing on the corporate if delivery use cases We're using the examples to provision on the one of the application and the underlying infrastructure with All the CNCF projects that are out there On the working groups they cooperate if delivery working groups in the working group that specifically deals with how app delivery infrastructure delivery and the processes in between fit Together has that draft charter available under the link here. We also send it to the TLC mailing list to get the approval. Some of you have already voted some have not yet voted. So If you have any questions, please let us know and if you have not voted yet, it would be great to get your vote and on the case engineering side, it is still a work in Progress so but there we should have to work in group charter finished by the sooner than later as well. So that's it from app delivery. Any questions please Question the cooperative delivery working group. Is that is that one in the same. Is that formally known as the get ops working group. No, that's not the Group that's the one that deals with the problem that F and infrastructure delivery are often disconnected and you have to have a lot of handovers a lot of dependencies. We see got you. Okay, having that situation that in many communities use cases, some cluster is also provisioning the underlying infrastructure and their dependencies and requirements. So it was mostly driven by folks working on infrastructure sites and problems to run with on the app side. Again, this is the best name we could come up for there is still a contest out there for a better voting, which has came up with corporate is because like really bring infrastructure and to gather and ensuring that something you actually write in your YAML files on the application side can later on the deployment infrastructure. Because storage classes are supported networks are supported and if not you can check it actually before deploying it. Instead of having it in some cases fail silently or not not not work at all. So that that's what they're dealing with. Again, naming is hard as least pointed out. But at least everybody remembers it because nobody but everybody's to think of it's what it's doing but that's what it's what it's about. I think eventually there's also for sick network things that's coming to play like with blue green deployments and things like this when we start to work on this. Yeah, not to imply that the other working groups aren't cooperative, but in one other question if I might. Do you have a sense of, like how much of the focus of the working group is on the softer, the human side of things like the softer side of there being an infra team and an apps team and and and how how how centralized YAML or a single file that describes concerns for both teams. Like, I guess what I'm trying to figure out is how much of the focus is on soft psychological human gooey sticky things versus you know binary systems software stuff. Obviously at the end of the day, oh, humans have to write those YAML files in most cases. I think it's a combination of both it's really the processes that these different teams have like looking into different release cycle is the processes and how they work with other work and get things done out there but the focus is still very much how can we produce artifacts and have processes that these artifacts eventually work together so it's not like your agile type of approach for cloud natives to be not going like that far on the human and process side. It's ensuring that what falls out at the end of what is independent teams are working on eventually fits fits together. If at the later point in time we come up with something that's more related to okay this is how your team should work together. So we have actually found people working together we had a longer discussion also to not just obviously come up with the white paper by ideas that we have within the working group. Part of our work is to talk to people and companies who are doing this already at scale and getting their best practices and how to make this work so we plan is not like we invent the wheel. We're actually having a collection of all of the good practices that are already available there and if more process and organization stuff will fall out I think it will find its way to some document. But right now it's really about the hard technical issues that you might run into other people used to run into by running community space workloads and having like this infrastructure and that side of things. So I think you had a question. You were very very muted. Sorry. So, other than the white paper, the chaos engineering working group, what other kind of things are they thinking about for the future. We started guides also best practices. So there's a lot of dust but the white paper like the bigger one but also like how you get started, which type of tests, you could be running giving people an overview. So the interesting thing here is on the chaos engineering working group. It became evident very early on that this is not just something that's related to app delivery. There's an activity that spends multiple working groups will be immediately started obviously talk to networking because of network chaos, then to security but security chaos and obviously for doing all of this chaos related works you also want to know whether the system actually can deal with the chaos and not which then directly brings you to observability as well so I think there's also a lot of work that side brings all those people together. This is also why it takes a bit longer like to get the working group like form because it's a lot of people that are involved in there but people very actively from the different teams take part in it. Awesome. Nice to hear. Thank you. To what extent is cooperative delivery related to what people might describe as a platform team. I think it's the combination of the platform and an app team working together so that it like kind of really works, works pretty well. So the people we have in there are those that are used to be in both sides like the ones building the applications and the ones building the platform. And it's a lot of the things that usually don't go well together. And this happens in independent teams. There are a couple of examples in the in the charter in there like for example you use people assume that it because in their deaf environment to have storage classes available that suddenly not available in the production environment or a certain version of an application requires certain infrastructure components all the way down to Cal resources to be provisioned which are usually not part of the application definition but the platform definition but you still have this dependency application code in there so how you can model these kind of things is that as people start to use the tooling but what kind of became obvious. We have tools pretty much for everything and we can do everything for me this so we can even use could believe this in CRD and various projects that are out there like it could even provision cloud resources but it's almost like there's the infrastructure to some extent platform side and then there's the application side, but there's like no common view of like bringing both together and ensuring that they're working together nicely. I hope I made that point clear. Any other questions for Alice and tag at delivery. Okay, thank you very much. Is it network next. Yeah, that work. All right. We have a new co chair, Ed Warnacky. Yay. I can see there's a yes. Yes, this has been a long time coming. Good. Ed. So many of you gave some positive plus ones to the suggestion that Ed would come in he he's put some new life into the what I'm seeing network is doing, and hopefully, I'm deliver on part of the charter of, well, Jesus just said see network but of what tag network is doing. And boy what's worse is that some of you didn't catch it I think that's even work. And, and make sure that we're on a rotational basis inviting in various projects within the tag also various working groups within Kubernetes to have a form of exchange or just there's a lot that goes on between the projects and not everyone always has time to exchange some of those thoughts and things so particular to networking there's there's a fair bit there's a fair bit going on there's So anyway that's part of the charter is to, and we haven't done a whole lot of that and that's primarily based on bandwidth. Welcome, Ed. The last couple of calls that tag network has had have been light on project reviews light on business, if you will for tag network, although psyllium and chaos mesh are both up for incubation and both at least psyllium for sure is out for voting. And I think chaos mesh is a little bit earlier in the process. The what what the what we have been able to spend time on is in the service mesh working group. There's, I guess, a couple of things items highlighted so under the service mesh performance group, the folks at Intel, a couple of folks at Intel at Red Hat and layer five have in coordination with Ken Owens drafted a publication for IEEE if you're interested in that sort of thing there's a there's a link to the final draft. And that talks about the approaches to performance measurement in context of a service mesh. Next item up was that one of the programs one of the initiatives inside of that the service mesh working group is that of SMI conformance. And so, since last we've met here, both open service mesh is a merge away from reporting their conformance on a release by release basis. So that's great they're kind of getting into into the system, by which they would automatically report conformance and Gen X service mesh should been joining the calls most recently and is also now manually reporting their conformance but so that's great. The last item last highlighted item here is just on the topic of service mesh patterns and identifying best practices for various pieces of functionality that service mesh is offer characterizing those into a service mesh agnostic pattern. Some of that effort will fruit or will be demonstrated at service mesh con so that's nice for those that have been working on the patterns. And that's that's the update. Lee. Quick question. What is the overlap or, you know, how do you work with the say the CNF working group. Yeah, good question. Um, so by the way, is the CNF working group under any tag. That's why I was asking. I think it's part of the telco user great isn't it. Yeah, or is the Genesis of well or a slight point of confusion my best so this is grain of salt. This is my best understanding is that the fine folks have been working in the tug or the telco telco user group had wanted to sort of, you know, formalize in advance, a component of what they discussed or what it like the, the, I think primarily like testing and analyzing a performance of cloud native network functions, and hence the working group CNF working group and had kind of a little while ago looked been had proposed that working group looked for a home sort of between app delivery, tag app delivery and tag network, and became established. I don't know that they necessarily hang out in one of the two groups. You per se. Good that's on the maybe the softer side of sort of organizationally the, I'm talking all about a lot of gooey and and hard things today I don't know why, but anyway the harder more technical side. There is. Well, I think the Genesis of that working group having come from the telco user group or tug should is an indication should indicate like that you have a lot of the. There's a distinction in. They are service mesh provide or serve I'm sorry she service mesh their service provider focused. More like. So, VNF's and CNF's are of that of that genre of networking, if you will, which is touches up against but is distinct, it's nuanced very nuanced but it's distinct from some of the more enterprise centric use cases of how some of the other projects are used so like it like is uses a lot of the same network words, but the folks that are interested or the use cases and those that are involved are end up being highly highly related highly. Like if you take a look at the performance tests that are being done in this CNF working group, and those are being done and like the service mesh performance project. They're being done on 5G are like, but right now the, the, the type of applications and the type of network functions that are being analyzed are the running in different environments under different. And they're hence using different test harnesses and. Yeah, I understand that. You know, how everybody's related to the reason for asking this question is like in the end, they use all the projects that come from like, you know, under the tag network. So if there is a good feedback loop between the tag network and the CNF, it will be beneficial is my feeling, you know, if they are on their own, not like getting things back to us then, you know, you're missing an opportunity for you. I don't pay. I'd express the similar opinion previously. I don't know. Yeah. Thank you. Yeah. I think from the. Early days of it being set up the user group were very keen on having those discussions without vendors present. And I guess that's why it's a separate group that separate from TSE because TSE groups don't have restrictions on, you know, they're open to anybody. And that may be historically wise in that user group side, but I completely agree if there was like overlap between personnel who were involved in that user group and in tag network that would be really useful. Just a quick clarification just and I don't know if there is a, there's, I think, you know, the sort of three into three groups here that end user service mesh working group which get to Liz's point is vendor free. Actually they had reached the I actually presented at their last meeting they were really curious about some of the projects are going on here. And so yeah, vendor free the service mesh working group here. Vendored, but then the CNF working group. I think is what dims is. Okay, cool. Cool. Any other questions about tag network. My alphabetic skills have failed me. Hello. I don't think we have a leader here, at least she wasn't here earlier. Are you here. So yeah, we also have a third coach in our leader shower of AWS. She was to just devoted in last month. But she's not here to say hi but she's in. Also, I think met had a few points. Also, we had a break in August. Over to you met for for the rest. I think you put that in. Yeah, the third one there should be gone. I think I timed it wrong when, when, when the meeting started that that's that's for the future. And as Richie said, we're coming back from August break. We've got a new co-chair. We're very excited about that. A little later joins us and brings quite a bit of domain expertise, as well as vision and experience building communities. So we're extremely psyched and enthusiastic about that. Our first meeting in an hour just after this, and we'll be revisiting where we were back in July. So we have a number of work streams. Everything from the YouTube channel, which I think we can do a lot more with, as well as we're going to be looking to recruit additional tech leads this fall. So if anyone has recommendations or referrals, please pass them along to one of the coaches. And that's pretty much it. We'll keep it short and sweet today. We're looking forward to, I guess, Q for all however you want to place it. Okay. Any other questions for observability folks. All right. What's next runtime? Do we have anyone from runtime here? Yeah. Oh, hey, Ricardo. Hi, everyone. Yeah, so some quick updates for tag runtime. We had some presentations in our meeting. So in the containers and runtime space, we had this presentation for confidential containers. The folks are working on confidential computing. They have this new project and they're thinking about applying for sandbox. This is a project backed by a lot of big companies, Intel, Apple, Red Hat, IBM, AMD, so a lot of a lot of backing from this project. This is a way to run, you know, like workloads that are fully protected in cloud service providers. So places where you don't own the hardware. So people are able to run the workloads in a secure way and being verified, being encrypted and all the good stuff with security. So in the machine learning, machine learning at artificial intelligence space, so we had a presentation from volcano. This is a project that allows you to run batch workloads on top of Kubernetes. The presentation is about incubation. So they're trying to go for incubation and they're looking for a sponsor, a TOC sponsor. So if anyone interested in sponsoring to take this project forward, it tackles an area that there's a, there's a gap, you know, in terms of batch workloads for Kubernetes. Another project that we had our presentation from, what's MLflow, this is end-to-end machine learning and it's a really big project that's similar to Kubeflow, so very, very large community. So hopefully we get some interest from those folks to, you know, to participate more in the CNCF activities. KubeDL, another project in Sandbox and the CNCF and it allows you to run deep learning workloads. So taking your model from training to production, so it's currently in Sandbox. So they're looking to grow and possibly go into incubation sometime in the future. And finally in this space that we reached out to the MLops community, so we're asking for more participation so that we have more in this space, you know, projects that are interested in presenting in our meetings. And for tag runtime activities, we're still working on a logo, so that's in progress. Hopefully we'll have that ready in the next few weeks. And the container orchestrated device working group, Renault, which was the main chair of the working group step down, so Alex Kineski from Intel will be handling most of the activities. And we have some interest from the confidential containers community that possibly they want to create a working group, but that's in progress so that may come after they apply for Sandbox. And finally for KubeCon North America, in China we have tag sessions, tag runtime sessions, so we want to get more exposure and hopefully get more people involved. And the one in North America is going to be an in-person session. And yeah, that's all for the updates. Happy to take any questions. Thanks, Ricardo. One, sorry, go ahead. I was just curious if there's an overlap between confidential containers and Cata containers. Yeah, so it's the same community, but the Cata containers could be one of the components that they can use, but they can use other runtimes or their VM type of runtimes. Also proposed lift cave run, I think that will actually make it possible to run confidential containers. So yeah, so there's some overlap in a way, but it's not exactly the same. Yeah, they are actually the Cata container folks are using container D and there is a POC in container D as well, where they're experimenting on some of this stuff. Yes. The one question I had, Ricardo, is awesome folks, right? There's a bunch of awesome projects under in tag runtime. How are they working with each other or how are they cooperating? Is there anything going on where? Yeah, we're talking to each other. We had a few projects present. So in the last one was Wasm Cloud, Liam Randall is the lead for that project and he actually set up the Cloud Wasm Day event at the KubeCon. So he's actually in contact with some of those folks. But we, I think it will be a good idea to maybe reach out to them and see if there's something that we can do in terms of like creating a working group. But yeah, we didn't, we don't have a lot of base for Wasm this time, but we've actually done quite a bit in the past. But going forward, I think a good idea will be to create some sort of working groups that they actually work together. And Liam working on Wasm Cloud has actually started with the, you know, the Wasm Cloud Wasm Day event and the idea there's also to get more participation from the community and more traction in some of those projects. Thank you. Okay. Unless there are any other questions about runtime. Thank you. Let's go to security. Hey, so we have just one update, but it's a big update. We've finally brought to completion the assessment of cloud native build packs. This has been going on for quite some time since April of last year. And extremely high praise for the diligence and rigor from the maintainers of cloud native build packs and how responsive they were throughout the whole process and tire length. And they were absolutely prompt to resolve any questions respond to any feedback that the assess that the assessors had for them. A couple of notable things while the project is watertight at two different dimensions. One is well the the outputs of build packs, the container images that are generated using build packs tooling do a lot of assurance to avoid by container security best practices. Examples are all processes must use non root user or group identifiers at build time and generation built and run images are done separately. All variables are specified separately if reproducibility is supported. Build pack does ensure bit by bit reproducibility of these artifacts. Then the the other layer is how well the project follows secure development best practices. While we're doing the assessment we're able to do the CIA best practices for the project and it was just the breeze, feeling all filling out all the security criteria, because they were meeting it already. Notably, in addition to that the project team also started signing their life cycle images using cosine and generating cycling DX S bombs for further releases. So, all in all, really good assessment. About to merge it soon. We're playing a little bit with the Google Docs API to export all resolved comments. So people get more visibility and transparency into what were they assessed against what was the kind of feedback how did they responded to it. They did put a lot of effort in and rewarding this yet the assessment itself so that questions wouldn't arise in first place so the assessment document as it stands should be a good enough reference. The recommendation to CNCF is to circulate that assessment as a vehicle to improve awareness of the project and how it compares and contrasts to ecosystem alternatives when it comes to security properties. That's it for the assessment some administrative stuff regarding assessments. We were a little bit backtracked with other assessments that that were in the pipeline ahead of this one. Also that the project due diligence for incubation bypassed the security assessment. And it also influenced that we didn't have a really strong sense of urgency to to knock this one out from the get go, and it kind of became victim to other priorities. So, yeah, determining whether assessments are mandatory for due diligence is what would help us. And prioritize these better. And then with, well, it's been it's been a hard year for everyone so lots of job changes lots of people taking leave, and that that also affected a little bit of the length of the whole assessment but once again should be should be checked in pretty soon. We'll send an update to the group once it is happy to take any questions of their hand. I don't know if I have questions about build packs. I don't know if you're the best person to answer it. Could people could people today just be swapping out the existing images built with typically Docker build and just replacing them with build packs and the world will be a safer place. The second thing is, yes, there is almost zero heavy lifting involved. And it's quite swappable. As you've said, I also have Matthew Giasa, who was involved in the assessment. Matthew I don't know if you can speak more detail to that, as we'll just defer it to the to the project team and come back with a response. We'll see him here. I think might have just dropped. Okay, let me let me take it as an AI. But yeah, I think that's that's going to be the question in people's minds like, you know, can people use their existing registry and just be storing build packs in the same registry and you know like what's the process for people to move to build packs. Okay, they may already have that documented somewhere but that's that's my kind of initial reaction to that recommendation is okay if it's easy for people to make this change. Let's encourage it but I think we need to understand what that process of making the change involves. One of the things that I think is really interesting about this is that in practice, the build packs are are most often maintained by the platform team, which is one of the ways that things get more secure is because you've got a platform team who often take on the responsibilities for security and then organization, maintaining these build packs, essentially maintaining the image building process. And then we have app teams that just use them. I think that what's so interesting is the parallel to the conversation that Eloise was talking about earlier when he was talking about YAML and platform teams and app teams. There's, there's a crossover from there. There's a relationship to what we're talking about here with build packs so build packs are very specific technique that I think addresses that coordination. And that cooperation between the platform team I love how you called that out earlier Liz that you were saying isn't this platform, platform team app team it's that cooperation. And so build packs are part of that cooperation as well. That's really interesting. I love us if you're still here. I'd love to hear your reaction to to this. Yeah, I think it is it is one of the projects that we listed as well as one of those that should be in there. There's a lot of the supply chain security concerns as well using using build packs. I think there's still the unresolved issue is what about like all the other YAML configurations that go beyond just a container image. And we have seen some projects that have interesting approaches there as well conceptually very similar like you can't use the pure YAML and anymore just get access to value files for more less predefined templates. I think there's also some interesting developments there and where people build these high level components in Kubernetes like you can say I have a service and I want to have it exposed to the to the internet. And this is where my image is coming from this is my URL just parameters like this, and on CNCF project we were, for example talking to was gimlet but very small but interesting project. And so we see if the knows about those platform teams because they can say well what you can build whatever you want to do your application developer but this is what it's supposed to look like these are the network policies you need to have these are the network routes. These are the security roles that need to be there. This is a similar concept. It exists exist as well. That's not the part of bill packs, but bill packs fit in there as well. But that other area will also be one I think we're going to see more, more and more people working in the direction because conceptually that's what bill packs do the more less that you just keep the application specific parts, and the rest is injected underneath and also updated automatically. And similar things for configuration. Artifacts like but it's YAML, pure YAML and charts I think we will see a more of that as well from a simplicity and a security perspective so that that's exactly the direction which which we're looking into as well. I think there's also an overlap with runtime but some of the confidential computing containers. You know part of their work that they're doing is actually, you know pulling out like an encrypted image or encrypted workload artifact and making it run in a secure way so there's, there's overlap without delivery runtime and security and possibly storage to you know how you store securely store your containers. It's a very interesting space. Yeah, I feel quite ignorant about what the kind of processes here for people who want to move to build packs what that involves I think that could be a really interesting thing to understand because like build packs are a good thing and solve some problems particularly for security so yeah. You know, for fairness to the assessment authors who handed us to have it scrutinized, they did detail that in the document, but being security folks we've just zoomed in and to the security design. I would encourage folks just to click on the link, flip through it. They do a great job writing up like the intended use and as Cornelio was saying they do highlight very well like the shared responsibilities model and how like platform and app teams are meant to cooperate through build packs and like what responsibility falls on on whose side. So, they do have quite a bit of that and writing and like this assessments are great for that purpose to get people like a quick deep dive on on certain practical things of the project so just wanted to bring that up. So, quick question here, keying off of what Liz was saying. And what is in the text that is being presented. So the assessment team strongly suggests evaluating awareness of the project. Right. So what tools do we have in CNCF that we can help make this happen I guess. Because if we were talking about like, okay, people need to move from Docker to CNAB and that would be better for security right like how do we get the word out. Yeah, of the services provided to projects depending on the tier there and their number of like information dissemination or like marketing opportunities, be it webinars, be it social media, be it well let's let's take from this assessment the those parts that were we're talking about of like hey how do you migrate from this to that and why would you in first place like writing up the value prop like really crisp and really succinct. So it's not like a 10 or 12 page document, I think can can go long ways. These are just ideas and I'm spitballing here because I hadn't anticipated that question. And it's something throughout assessments we find in the summer we always suggest like, hey let's do a little bit more marketing for for this project that might be like an expert level system and not like the rest of the ecosystem is not aware for any number of reasons. Yeah, I could really imagine you know maybe the the projects, you know, writing some material to help on this, but also if we had like end users who had actually done that transition and could share how that had gone. I could see that being really valuable. And I guess the bill packs project is probably the people who are best placed to know who's done it. So, I hope we can put that into their court but you know with support from CNCF that we because from everything I'm hearing this sounds very positive. It probably involves things like you know, how do we get people to use examples that use bill packs instead of Docker files and how do we get people to, you know, just as they're talking about delivering applications, you know, how do we make the default choice, the more modern choice. And that's a remember from the due diligence review and I don't want to do them wrong it might have changed in between I think they could put a bit more into especially the examples. Because I know when I was reviewing it, they had the examples but they were not necessarily most useful ones if you would just wanted to build your container. It's been changed since that due diligence but I agree I think this is, I think it is a bit of more of a learning curve if you want to do it with bill packs than with your Docker file. I think as soon as you move to a reasonable structure of your Docker file and take care of security concerns. The additional effort is well work actually becomes less and obviously be would be worth it. I agree with your list I think maybe having more examples on how to use bill packs instead of Docker especially right now is a whole discussion about software supply chain security. I think it perfectly hits there. Awesome. Well hopefully this discussion can invigorate the project team to to help come up with some of these examples. Any other questions? I'll relay that to them. I will relay that to them and make sure that those examples if they do exist that they're discoverable because that's typically the other challenge. Things exist but people don't know how to get to them. Thank you. Thank you, Andres. Any other questions about security tag? Thank you so much for bringing that up. That was really useful. Thanks storage. So, a bit of an update on the projects going through review. The Longhorn project is the DVDs is completed. And we've sent to Saad for review he's he's provided a few comments back last night, which we're just going through, but that should be done shortly. We're hoping to complete that soon as well. Open EBS. There has been a bit of movement there the team have been getting some of the licensing and copyright and variety of other challenges sort of that which they've been working on. And they're going to and we're going to pencil in a call with the team next week. And then we'll be able to make a recommendation as to as to how to proceed there. Also, on on the project reviews, one of the, one of the things that Saad has asked us for is to to to get guidance on how to deal with multiple, sort of multiple solutions. And sort of trying to come up with a strategy for for for how we decide and compare which ones should be incubated and graduated whether you know it's all of them or some of them or or or how we differentiate with them. So we're going to discuss that on the on attack call tomorrow. But also, sort of, I'd love to open it up to the floor if there are any, you know, particular particular bits of feedback that the TOC could share there. Finally, the we've been working on a couple of documents the cloud native disaster recovery doc is is done. And, and I think we're we're kind of ready to release that now and we have the performance and benchmarking white paper which which sort of had a bit of a stall for a few months. But now Nick has picked this up and has reviewed drafts and we've got a final section to be finished off and and then I think we're done and should be ready in time for a coupon. I think that was it. Great. Thank you. So I guess you asked for thoughts about, you know how we deal with the situation of three kind of similar projects. You know, and how we evaluate the three. I mean, for me, what I'd love to see is what is the difference between them, you know, what is the clear air that makes one different from another. And that, you know, helps helps us understand, you know, are there situations where we would want to recommend a and other situations where we would want to recommend be. And if there's another situation if there's no situation where C is the best option then I'm not sure why we would want all three, if that makes any sense. Well, so open question. You know, there's obviously each of the projects will have a variety of you know pros and cons even if they solve similar problems. And certainly within the CNC F we already have a lot of overlaps in, you know, different projects whether it's, you know, runtime or observability or whatever else. And so the question is, you know, is it should we be proposing like a recommendation to include or not include one or the other based on based on the fact that they have similar use cases or, or, should we, or should we, you know, have multiple options like, like we have in in sort of other technology areas in the CNC F. So I think wherever we have multiple options. It's no bad thing to have multiple options it's good to give people choice and we're trying not to be prescriptive and we're trying not to be king makers, but every time we have multiple solutions it adds some uncertainty for end users. And if if that uncertainty is is kind of unnecessary because in fact no reasonable person would choose one of those three options given the other two, then. Right. And I'm not saying that that's the case with these three but you know if if there were two that were definitely better than a third then I would much rather that we don't try and pretend that all three are on the same level if that makes sense. But it's very likely that all three have some strengths at which they excel or some environment where they're the best suited and if that's the case let's try and be as clear as we can to end users to sort of clarify why we think those three projects are worth sustaining and using. Yeah. Yeah, that makes sense. Anyone else has thoughts please do chime in on that that's just my kind of interpretation. I like that less. What I was thinking, you know, similar to that was like, is there like a matrix of, okay, these are the features and here are the projects. So you have a matrix where people can like figure out like, okay, based on these things, let me pick, let me start with one of these, rather than the other ones right and then, you know, I'm just thinking like what is the decision making process for an end user to go through these projects and would they just pick one in random or can can we give them some guidance, like, like one page matrix saying here are the list of features or list of things that you need to look at is where each of these, you know, storage options are useful. Come up with something that will help them like pick the first one. Hey Alex I'm also wondering do these projects have any adoption stats of their own, you know should see and see if I have some kind of a common service discipline that tracks that because you know it's one thing for us to evaluate and recommend but I mean these projects have been growing on their own for a while so they need to be able to demonstrate some degree of adoption. Otherwise, I mean I think that I would, I think that speaks more to the viability of the project than anything else. I mean, look, I agree with that there's, there is sort of a an implicit assumption that if the project passes a due diligence at incubation level that's you know there are end users using it in production and adoption stats and maintainer stats and all. I think all the comments are minimal right like three users or whatever so so if you know if one had a millions of deployments the other one has a thousand deployments then then it's pretty obvious you know which one is really leading so so that that's what I mean is there is there is there. Something like that would actually very helpful from the user perspective. Another sort of more qualitative assessment might be asking those users why they picked the ones that they picked you know were they, you know, if they picked a was that because that was the one they were familiar with other particular tendencies with one ecosystem to pick one solution over another. You know, we saw that with run times right that there were certain ecosystems that were more likely to use container D and others that were more likely to use cryo that kind of it becomes their valid choices and tend to go along with the ecosystem you're in. Well, yeah I mean, those are the kind of the sort of things I was referring to right I mean, you know, assuming, assuming that there are always going to be some differences because obviously every product is is slightly different. And they're presumably going to have different users. We seem to have, you know, like just off the top of my head container D and cryo or, you know, Prometheus Thanos and Cortex or, you know, linker D and then boy, all have, you know, large large overlaps today. And the question is, you know, do we kind of standardize how we compare these things that we standardize how we provide guidance for these things or I mean, in some cases maybe it's more click cut than other than others I guess but. Yeah, I think we're going to run out of time to foolish flesh out that answer. I do think if there are ways we can compare names around Tom has suggested about having metrics that we can compare performance metrics I think I don't think that's the be all an end all. I do think if there are metrics that would be useful. Yeah, maybe maybe it's something we can pick up in the next meeting. Yes, indeed. Let's put that on the agenda. Yeah. All right, in the last 30 seconds, I guess, if anyone who is I know most of the people who are. The responses for these are not on the call but if anyone does have updates, please shout out now. Amy, can we add the volcano to the list of your projects waiting for sponsors. Yeah, we should probably try and put those. I know we can run into the meeting. Yeah. I think it's helpful if we make it prominent how many are waiting. Change that for next time. That's fine. All right, great. Thank you. All right, we're pretty much up to the top of the hour so I think we probably have to call it a day but thank you everyone for your time and lots of really useful discussions today. Thanks everyone. Thank you.