 Okay. Yeah, we are recording all right. Thanks to you see members for joining us today. So we're, we've got a bunch of projects lined up in the upcoming portion that we're going to be looking at today. However, I did want to take a few moments this morning and talk about sandbox, what it is, what it means. We've been getting a lot more questions and the queue for sandbox applications as well as sandbox projects is getting quite long. So I wanted to kind of come back to what is the sandbox and what is the intent of it. I wanted to have just a brief discussion around this. So originally it was intended for early stage projects that we believe weren't experimentation. And we have some definitions for early stage that are reasonably well defined functionality interoperability libraries extending those projects, independent projects that are novel to existing functional areas or attempting to meet a need that is currently unfulfilled sanctioned by CNCF or commissioned and any project that realistically wants to set foundations for incubation. So that's kind of the background associated with why sandbox and the reason why I wanted to bring it up is because we've been seeing a lot more applications of projects come in that provide just a slightly different take on existing spaces within the ecosystem. So there's not a lot of experimentation necessarily that's warranted further. Rather, it's just a different approach that they may be taking provides different value, different feature set. That's not necessarily bad, but something that we should be considering as we're reviewing these. We want to provide a collaborative human environment for projects that are coming in that we believe are set up to successfully turn into highly mature projects. And we've had discussions in the past about, well, it's cloud native, there's a need, but we're not necessarily going to see it fully go the way of Kubernetes, or some of our other graduated projects have, but it's still necessary within the ecosystem. So try to keep a lot of this in mind as we have any conversations about the projects considerations for where they're headed. There's a roadmap look like I wanted to ask you all, do you all have other observations, things that you're seeing with some of the applications today or in the past that would be worthwhile to call out? I have an observation. So sometimes I see the project, the scope is very, it's, it's narrow, it's small. So the chance of it becoming, you know, much, I mean, build a large, build a good community and also become very, you know, a mature project. It's not very, I think that that's one thing may not be, as a good, may not have a good potential. How we should deal with that. Yeah, I think that's something that we should discuss probably on a per project application basis. How do others kind of feel around this space? Can you hear me? Go ahead, go ahead, Erin. Sorry, I'm driving so hopefully my signal stays. I don't know. I mean, given the feedback on the governing board meeting, I'm curious if anyone else has given a lot of thought to not continuing to invest in Sandbox as one of the levels. Not continuing to invest in Sandbox and what was the last part of your statement? As, as one of the project levels, like, I mean, I was in the conversations when we started Sandbox and what it was going to be and why we needed it very early on in the CNCS, you know, maturity and now I am curious. Initially, it wasn't something I think I would ever consider, but the more I look at the value we're providing and the feedback from the community, is this level providing even the value that people believe that it should be? We've always struggled with that, right? And is it preventing us from being able to nurture and care for the projects that are in incubation and graduation stage? I guess I'd like everyone to kind of consider those things. Yeah, I agree. I mean, I haven't thought about the last part, but is it providing the value that people expect at Sandbox? And I think, you know, as I look through some of these applications, the value that I think some folks expect isn't what we've documented. And I don't know if it's us communicating or that or not because if you look at this, you know, it's projects that warrant experimentation, right? It's for things that need, say, a non-vendor neutral home, right? You've got a couple of vendors or a few vendors who want to work on something and it's in that early stage, but they need a place to go do it together. It's for things like that. And as I repeatedly read what people are asking for, they're like, it will bring a community to us, but it doesn't. We'll be able to get advertising, essentially. You know, we'll be more seen, not at the Sandbox level. And so, somewhere there is a mismatch between what they're looking for and what the CNCF provides. I think there's a place for that early experimentation when you need a, you know, a vendor neutral home, but I think it's a lot rarer than we sometimes see. Yep. And we'll see that actually a lot in some of the applications today. So, if we want to get started, any other, like, final comments on this while we're thinking about this and reviewing applications? Yeah. I mean, I'll say two things. One is, you know, I think we should try to do a data-driven approach and kind of like ask the Sandbox projects. And as Justin alluded in the chat, you know, maybe projects went from Sandbox incubation. I got to see how that is because, you know, they generally don't get much from CNCF in the early days right outside of like doing paperwork, you know, to ensure kind of the neutrality, you know, cleaning up governance, which is work on their end. And, you know, maybe an opportunity like to participate in like a project pavilion or something, you know, something or office hours at KubeCon, right, depending what we offer at the time. So it's generally not too much of stuff that Sandbox projects necessarily get. But I do think people find that valuable and just like being being part of a larger area where it's seen as a place to collaborate openly with, you know, companies, vendors, and all that stuff. So that's kind of my observation there. And then on the, I think to Kathy's point earlier, it's like, if you look at the projects, you have like stuff that is like higher up the stack in some ways, like things that don't really depend on Kubernetes, but are kind of part of our, you know, march up the stack, whether it's observability, or things like backstage, you know, which, you know, could be easily used without Kubernetes, and then stuff that's like, maybe really low, right, whether it's like EBPF or even kernel, you know, level, which historically we didn't really have in CNCF, because we could kind of consider that stuff almost out of scope. So it's kind of like an expanding of scope from like a top and a little bit of the bottom, if that makes sense. Yeah, Tuffy. Yeah, I was going to say, I think administratively, sandbox is actually kind of a burden, because as it represents a pretty significant pipeline of projects that are coming in, there's a lot of due diligence, there's a lot of, there's a lot more work there involved. I think that isn't represented necessarily by that statement. And I think the question becomes like, where should the beginning of that work sit? Should it be when projects are further along, whether they, whether they have actually moved to the place where they're ready to commit to an incubation status rather than to a sandbox status, so that we can better align the amount of work with the amount of workers, as it were, you know. Chris had asked about work for home, the project or CNCF, and I think it's a balance between mostly on the project side, as well as the tags and the TOC and anyone else that's interested in the project. I think this is an important call out, and I was talking with someone about this yesterday, is that we spend a fair amount of time looking over the applications, researching and understanding these projects, what it is that they're trying to accomplish, what is their current posture, and then there's the annual reviews that go on top of that. And we don't have the equivalent level of care currently today with projects that are at incubating or even graduating level, and this is a community concern that's been brought up, and it's a TOC concern as well, so we need to figure out how to strike a balance, and we've got some discussions happening later this year on that. So I think as long as we're highlighting and keeping these concerns in mind, I think we can continue to move forward with the reviews. Sound good? One quick question, my last one. I think that we discussed we're going to move the review of sandbox policy to PAC, is that right? Yeah, that's in progress actually, hello. Yeah. Can you spend a few moments talking about plans for that one? I can de-cloak and come on in. So we had a discussion about this at KubeCon around how that was actually going to work. I've got some logistic kind of details running in place right now for how that would work more directly, but not yet ready for final review. So we're kind of working through some pieces around like how exactly we would distinguish like which project falls under which tag. So watch that space for more, tracking towards being able to have that be a June work stream. One comment on that. I mean, that is how we used to do things. And I think it was efficient to have projects with the SMEs that could properly give advice or technical, you know, opinions on different projects. But does it have to be something that requires so much care and feeding? I mean, let's go through the applications today, but I really do want people to walk away thinking about could we be best taking this rigor we have around sandbox and doing that instead for incubation and graduation and more efficient use of our time and that projects that want to get visibility and grow their community are simply put to the tags is on their agenda to present because that's that's really what they're getting out of it that they want to grow the community. That's the great place to grow it. And then there is no formality. And the other things like governance that you mentioned, Chris, neutrality, you know, those are requirements going into incubation and they're not into sandbox. So I don't know. I just, I feel like we still have to sign, we still have to sign stuff over at sandbox. Yeah, that also probably belongs on the table. Yeah. So we've got lots of discussion ideas. We have an upcoming meeting actually, if you'll take a look at our agenda to talk specifically around those topics. So let's get started with Xline. I wanted to kind of kick this off to what are your observations? Who wants to start the discussion on this one? It's a distributed KV storage for metadata management. I went through this. So I seem to have posted some questions on it uses some something called the once consensus particle. I would like to know what's the difference between that between that particle and the raft and the pixels, you know, which are more commonly known. That's one question, right? Because I think we need to understand that, you know, what what differentiates value does it add? I think it gives some, I think they also pose similar questions, but still the answer, I think, you know, it's not, I think it's not, it does not have enough information. Another thing is I look at the maintainer list, right? I cannot really, I think there's no maintainers name there, just some other, there are some other information there. The maintainers list, they do have that. It's linked actually within the issue. They do include the CURP protocol maintainer. Oh, okay. Okay. Okay, I see. As far as the information around the protocol and the differences, this one that you called out, I had, I did not find any information on it. I think it's up to the project to make sure that it becomes available through them for other individuals that have questions about it. Overall, though, how do we feel about the project and its current state, its roadmap that it has, whether or not this is an area of the ecosystem where we need to see more changes in development? Dustin and then Nikita. I mean, my kind of, I mean, I put a comment on the bottom about how they done any correctness testing. I mean, I think it's an area where it's a big investment to build one of these, you know, it builds a distributed system. It's not, I mean, it's not entirely clear to me what, you know, if we have a strong enough ecosystem for maintaining these projects given our issues with LCD. So, you know, I'm a little bit concerned about our ability to sustain contributors to these projects, but they are foundational in terms of what we're doing in cloud native. So I think they're, I think it's in Skype, but I'm a little bit concerned about, you know, is there going to be enough investment to make it work? Nikita and then Duffy. So they do have some blog posts that talk about how the code protocol is different than draft and taxes, but then I don't think they have documentation around it. So this could be one feedback from us. Second thing around maintenance, like they only have three contributors who have significant contribution. So I was kind of adding on to what Justin said, I think it might be worthwhile if they invested more time and like growing the number of contributors, improving their documentation maturity overall, and then maybe consider applying to the sandbox again. They also presented at tax storage recently, but I really haven't, I haven't heard any recommendation from tax storage on this. So maybe we go back and ask tax storage what they thought as well. Duffy, then Matt. I think it's captured there. It's a complex project to take on. And I feel like they're pretty early. Matt. Well, you know, I was looking at their reason for it, right? Because it's a project that could stand on its own. It doesn't need to be here. And one of the things is they're looking for support, such as legal assistance with, you know, with aspects of potential IP and trademark issues. No, I have no idea what this is, but they're not asking for some of the normal, hey, we'll think we'll get a bigger, stronger community, or we're going to get marketing out of it. They appear to have something there that they're looking for, or if not, they're at least know the right words to say to hint at us that there's something there. And so that might be a reason that they're looking for this vendor neutral home, is they're looking for a place for that. Yeah. And are there patent issues? And if there are patent issues, do we want the patent issues with the protocol? And I don't know what's going on here, but they do call something out there. Yep. I second everything that's been said so far. I think the patent issues, if those, if that's actually what they are, some of the other concerns, there's interesting freezing within YCNCF and the benefit to it. But I also want to echo Justin's point around at CD and the current challenges that we have in that space. So I think for us, this one is one that we need to be a little bit more deliberate and thoughtful of. Is there someone that is willing to point some of these questions back to the project? We can move it to waiting. I don't know that it's any place for us to render a decision anytime within the next two weeks. I don't know how others feel. Getting some head nods. Okay. Who wants to consolidate some of the feedback for the project and that way we can get more information on it and then figure out where to go next? There's a liaison for six torch. That's a good question. Okay. Thanks, Nikita. I appreciate it. Okay. Nikita, if you wouldn't mind assigning yourself to the issue for X-Line. Thank you so much. And Nikita, to help you, this recording will be up on YouTube as soon as it comes through. All right. Next up is Pipe CD. To get out of style, continuous delivery platform that provides deployment and operations experience for any application. Who wants to start the discussion? Yeah. I found the explanation of how it differs from Argo and Flux to be a little bit on the weak side. It felt to me like, I mean, there were some differences, but it wasn't clear to me that they were really that big. And so I kind of, I was a little bit, I'm a little bit... It's not clear to me that the differences are really fundamental. That was my kind of issue. I mean, there are some nuance, but is it really a big enough difference to build a community around it? It seemed a question to me. It's a single company project, largely, I think, as far as I can tell. They don't specifically state that, are some clarifying questions about who actually owns it right now. But yeah, it seemed to me that the differentiation was not very strong. And in a space where it seemed to me, we could go to a tag app delivery and ask them to discuss whether they feel it's sufficiently differentiated that it should affect others. I'm looking at it, and they're one of those who are, they're seeking visibility and community adoption. And they're looking for guidance around the whole community thing. And that's not something that we give out really at Sandbox. Community is something you need to go build on your own. So I think by joining the Sandbox, I think they may end up being a bit disappointed by not getting support on these things of YCNCF. And so that's the whole thing. I think this is one of those places where we might see a mismatch between expectation and what we provide at Sandbox level. I completely agree. I think this was one of the first examples I saw where there was a question around, we would like a community in the CNCF as a place for us to get contributors. I would also like to highlight that they state that they are production ready. However, the project doesn't seem to have enough maturity around the rest of it to kind of warrant that fully-fledged, highly-mature, very stable, lots of adoption, which is why it's applying for Sandbox. And Duffy, I think your point of, you mean CD Foundation? Yeah, the Continuous Delivery Foundation. There's a foundation for that specifically. Do we feel like we've had a good enough conversation around this one to warrant a decision in the next few weeks? I'm going to take silence as, yes. All right. Let's move on to the next one. So that one moves to a vote? Yes, that one moves to a vote. Thank you. CubeServiceStack provides a complete set of DevOps solutions and a lot of observability capabilities. If you've checked out their repo, they have a ton of sub-projects within it. All of those. Who would like to start the discussion on this one? Okay, I can. Very similar story to the last one. It looks like there is one maintainer that is contributing most of the code base as they self-identified. So there's not a lot of different perspectives coming into their project. They're also applying because they believe the CNCF is going to endorse their maturity and provide them with a community to get contributors. Beyond that, there's not much else here. Their reasoning and benefit to the landscape is fairly straightforward. I don't really see anything that's new and unique, anything that is significantly profound that would impact the ecosystem in a way that continues to move this forward. It certainly is nice to have centralized service for a lot of the observability needs that are coming out of different end users and adopters in this space, but I'm not 100% sure this is going to meet all of those needs or that those needs are well-documented for the project to be successful. What do others feel? Yeah, I think I feel the same way. It looks like this project covers, as you describe, covers a wide range of functionalities, but I do not see what is the differentiation or what is the real functionalities going to develop. It's not clearly documented. Others? There also seem to be a lot of hereditary copyright issues associated with this. Yep. This is the one that has a lot of comments around intellectual property and appropriate use of code. I think that this one has significant challenges as a result of that. We've seen this come up with other projects during Sandbox and we have an open issue on the TOC repo on the appropriate ways to include open source within projects that are applying. How would we like to proceed with this one? I think we need to say no. I think that the amount of work to get it into a state that we would feel comfortable just from a legal standpoint is possibly insurmountable and it doesn't add a lot of value. It's again just a slight swizzle. I just think it's not appropriate for what we're looking for in the foundation. If I also look at what they're asking for, they're asking for visibility and adoption again, which are things they're not going to get at the Sandbox level. It's a lot of work for us and I don't think that we're going to deliver and give them what they're looking for by joining. Anyone else? Okay. Amy, let's move this one to a vote. All right. Thank you. Next up, Cube Marine. It is an open source lightweight and powerful management tool built for end-to-end Kubernetes cluster deployment and maintenance. Who wants to start the discussion on this one? No, this is like a Python-based kind of like an installer for Kubernetes clusters. So this is what I think is a very scope-based scenario. It's just using Python language and it's another installer. So yeah, I do not see it as a lot of value. Yeah, go ahead, Duffy. I was saying it is interesting that it's a combination of two projects to make this project, Submariner and Calico's PGP stuff. Yeah, I was going to say that and also I guess I am seeing an uptick in more like operationally related tooling in the space. I mean, I think backstage is like the entry of that, but this is kind of dev space, operational space. It's kind of weird that it combines those two into something. I don't know. It feels more like a solution than a branding project. I guess that's the best way I can articulate it. That is how I was seeing it as well. So I'm going to highlight again. They're looking for CNCF to demonstrate the maturity of Cube Marine through their sandbox application. And since it is more solution oriented, it's not necessarily a project. I don't know that accepting it into Sandbox is going to make a significant amount of difference to their adoption. How do others feel? I can't see this thing really becoming like a large project in the future because of its solution orientation. I'm kind of stuck thinking I don't see how this moves. Yeah, I would agree. I think I don't know what the right special interest group in Kubernetes may be, but that it would probably be beneficial for the project to socialize with one of those SIGs to get more adoption. But I think if anyone else disagrees, just let me know. We can move this one to a vote as well. Okay. All right. It's on the vote. Moving on. All right. Next up is Kepler. Kepler is a efficient power level exporter that uses eBPF to probe CPU performance counters and Linux kernel trace points. Anyone like to start the discussion on this one? Well, it's nice that there's already three companies involved in submitting the application. So there's already kind of a wider piece of it. Mm-hmm. Kathy? Yeah, I think it feels so gap, you know, currently there's not, you know, there's not much, like, you know, the power or energy or, you know, systemity, you know, aware, you know, the scheduling or the, you know, resource management. Um, so I think this will feel that. Okay. Others? You know, it gets into the whole multi-vendor space. One of the things that we want is for multiple vendors to be able to work together under something, and having those multiple vendors, we already see that in the application. So that is one of the things that I like about it is giving them that vendor neutral home. Yep, I agree. I also think it works to try to standardize things across these vendors, which is nice in this space because sustainability is quickly becoming like enforceable in the UK. And so having, you know, it's kind of like a missions for cars, I guess I think about that, where it was measured completely different, you know, working together in a vendor neutral place to establish what a standard would be for measuring these things to be compliant is pretty important. So yeah, part of that. There's a lot of community momentum behind measuring the performance as well. So I think between coupler being presented at several Kubecons that are recently in a lot more discussion around it, I think this is a good project to probably move to a vote with anyone else? Let's head notes. Okay. All right. Next up is Loggy. Give me one second. There we go. Loggy is a lightweight cloud native event driven data collector, transformer and aggregator. Who would like to start the discussion on this one? It's very, I mean, it's kind of recent and last November, it was great. And it's, you know, kind of a lot of small contributors, but to really just two people. So it's kind of a priority stage. Yes, very early stage. They have some ideas on where they're headed. They're pretty large level on their roadmap. They're doing things slightly different, but I don't know that it's really novel or unique enough. I think the project needs to probably spend a little bit more time on refining where they're headed and what the differences that they're going to be providing within the ecosystem. How do others feel? I mean, again, if I look at there, why the CNCF, right, the CNCF will increase the visibility of the project to track more users and contributors and help us continually improve and make Loggy more widely applicable. And I think those are all things they're not going to get out of the sandbox. And so it's a little bit of a mismatch. Yep. Yeah, so I think to Matt's point, I observed that there are quite some parties whose goal is like that. So do we need to document this in the sandbox so that people know if their goal is like that? They may not, I mean, since they may not help them very much at the sandbox level. I think that'll come later when we start digging into the data-driven decisions around sandbox. But I think it's important to be mindful of. Erin, you came off mute. Yeah, I just think it would be something that would be better communicated through the observability work group, you know, like I guess there's a lot of different solutions in the space. And I'm not sure how novel just at first blush that it is. So, and confirm the other statements that were made around the value as well. Are we good to move this to vote? Sounds good. All right. One quick side note. I do think that when projects are contemplating whether to enter into sandbox, like what they put into like the Y CNCF piece, that they may actually think that they're going to get that value out of it, maybe not at sandbox, and they're not asking for that value out of a sandbox. Maybe they're asking for that value out of incubation or through the life cycle of this project under the CNCF. I'm just calling this out because I'm like, yeah. Thanks, Duffy. All right. So, this one will go to a vote, Amy. Sounds good. Moving on. Erie Canal. Erie Canal is a Kubernetes multi-cluster service API, MCS implementation, and provides MCS, Ingress, egress, and Gateway API for Kubernetes clusters. Who wants to start talking about this one? Yeah. It's a single-person contributor project, I think, but it's kind of isn't all go to sandbox. Yep. It's the open-source implementation of the multi-cluster service, which is still very early in CIG multi-cluster. I believe that is under alpha. However, Erie Canal says this is part of their commercial offering, and the KEP itself is not very old and dependent on the maturity of the topology API. So, I think there is a lot of things that still need to happen in this space. Highly recommend re-engaging with CIG multi-cluster to further the development of this project, but I don't know that it's at a point for us to be able to seriously consider it as sandbox. How do others deal? Matt? I'm looking at it, and it talks about things like when using the Erie Canal as an MCS provider, you have to use it with OSM Edge, which doesn't seem to be one of the things that they're handing over, but tied more to their product. So, that kind of decoupling between the project and whatever they're coming with a product isn't quite clear to me. I would say that if it's a SPAC implementation, I would expect that if we're going to take a SPAC implementation and it would be a collaborative one between multiple people trying to implement the SPAC as a would be the kind of logical starting point rather than a, and so some demonstration that it's a collaborative effort before coming in would seem right to me for if we want to bring a SPAC implementation and for a new SPAC. Okay. Folks feel that we can move this one to a vote? All right. Next up is Slim Toolkit. Slim Toolkit, also known as Dr. Slim, provides a way to inspect, optimize slim and debug containers. Quick highlight on this one, there is some identity and naming concerns associated with the project. Dims previously had an exchange with the applicant around that, so this will likely need to be turned over for some trademark and IP questions associated with the project. Who wants to start the discussion on this one? It's been around for a long time. It's widely used under its previous name, which would have been even less acceptable. Generally, I think I know that people are crazy about their good community stewards and I think it would seem to fit. It's a slightly weird part of the landscape. I don't know exactly where it fits, but I would think it would fit. So should this project, has this project gone and presented to the tech runtime? That looks like it's a project to slim down the container. Well, it's also for observing what's inside the container because what they found was that people couldn't slim down containers without understanding what the slimming process was doing and what was in their containers in the first place. I don't think it's really a runtime fit, either of that clearly. That's what I mean by it's difficult to know where to fit it in terms of tag. It does overlap, yeah. I mentioned also debugging the observability part, but you also mentioned the part that slimmed down the container size first. I would put it in app delivery because it's a developer tool. Roughly, it would be my reasoning. And I look at this as you develop something and now you want to go ship it and you need to shrink it down because we're sending and caching these giant things all over the place and that's a delivery problem. Yeah, it's also a bit security because a lot of the a lot of the artifacts that come out of this are a hardened image include a second pro policy. Like there's a lot of other stuff that actually overlaps on the security side. Yep. So, it sounds like we're having more discussion around where does this fit in the landscape, not necessarily whether or not it belongs within it. So I think from what I'm hearing it sounds like this can be moved to a vote, but I want to make sure that we have an opportunity to discuss any other potential concerns, caveats, call outs. Well, if we say no, what are we saying reapply? That's the thing is like I'm trying to get a handle on so what it means going for a vote here if it because it has been around a long time, you know, it is novel. Yep. So the the only other thing that I would suggest is that because it has been around for a long time, it does seem to have a fair amount of individuals that are using it that maybe sandbox isn't the correct place for it that maybe they should be applying to incubation. How do others feel? I hadn't really considered that angle. Yeah, they're going to have to make a bunch of changes to get to incubation. I don't think they've got a governance it's very heavy on one developer. And so they're going to need to make some changes that I don't think it's ready on a quick glance at it for incubation and what we're looking for these days. So do we tell them to clean those things up and bring it back for incubation? We always say come into the sandbox and start working towards incubation. Yeah, I mean, we've we've had a number of projects that have done the sandbox to incubation quite quickly and effectively. And I think that's a path to encourage because it gets them and it gives a commit that we think they can do it. Yeah, this is actually one of the values of sandbox is that once they enter that sandbox, then they're there because of the IP thing, they're actually in a situation where they can more easily attract other developers to contribute to the thing. Okay. Do we feel go ahead, Duffy. So they could actually move to incubation relatively quickly because of that. Do we feel like this one is good to go to a vote then? Head nods. All right. Next up is eraser. Eraser is a project that helps clean up unused and vulnerable container images from nodes in a Kubernetes cluster. Who would like to start the discussion? For me, I think this is incredibly useful. I've talked to a lot of security engineers and software engineers that are tired of getting bad vulnerability scans back from their running environments. So anything that helps clean up those vulnerable images that are cashed on disk would be ideal. However, it's not something that's top of mind for a lot of people. I can't see a lot of widespread adoption, but I do see this as a space where individuals that are already invested and interested in reducing some of those reports that come to them could provide value. Yes, I love the idea, but it's single vendor and it's single cloud. So I'd like to understand if this would work in AWS or GKE. I mean, maybe I missed that. I kind of assumed I needed kind of Kubernetes APIs, but I just had come out of Azure. That was my assumption and understanding as well. And sometimes it's not necessarily a blocker because when cloud custodian came in, they were only AWS-based, but they had aspirations to support other clouds. As long as that was clear, if this actually fell in that case, I think it would be okay at the sandbox level, but I haven't dived into this one yet. Yeah, I think this is useful. I think also they say, why CSF? They will grow the community of users and also contributors, right? So they could expand their scope or their usage to other cloud providers. This is something that we are often asked, which is, we look vulnerable from the registry, but what happens to the ones that are already running? And I guess this is in the same area, but cleaning up the local images, I guess also means stopping the workloads. And is there another project that is already doing this? Yeah, that's what I'm aware of. Because this cleans up the images, but what happens to the running workloads? This was my open question. What happens to the what? To the running workloads that are running vulnerable images. This has an impact on running workloads and just cleaning up vulnerable images can just be done like that in the production system. So that was my main question. How does this integrate with the chain of checking vulnerable images from the registry? The other thing that's tricky about this is the growth of the project. So this is a very specific use case. It kind of falls into the solution bucket. While I think this is valuable, I don't know how, I don't know that it would be able to really grow beyond its current scope or adopt a wide enough audience that current scope would make it a successful project. I think Ricardo has a good point on the direction of the project. And Duffy, you do as well. It's solution oriented right now. There's still an outstanding question associated with what happens to those running workloads. We've gone through and we've cleaned up all those vulnerable images that are cached. Great, but then what? So I think there is opportunity for future direction of the project if they're considering all of those challenges that come with it. But as it exists today, I'm not sure that it's in a good place. How do others feel? I think when they clean up the images, they're going to make sure there are no workloads that are going to use those images. I don't think they're going to remove the images when there are workloads that's running using those images, right? But of course, in the future, if there are new workloads that need to run on that node, I think they're probably going to download the images again from the image registry. Because here, I think they say they are going to remove these unused images. Of course, how they define that, how they make sure that that's a mechanism. But I think that's fundamental. They need to make sure when they remove the images, there are no workloads that are using that, using those images. Otherwise, the basic functionality will not work, right? It's a good question, but I think they should have taken care of it. Otherwise, how could they work if they just remove some images that work using those? That's a disaster. The question, Kathy, was more, that makes total sense, but it's more how do they plan to integrate with the rest? Because cleaning up unused images is useful. Then I can redeploy the workloads by pulling the image. There's a wall chain that should make sense. So we're getting a little bit into Armjure architecture here. I love doing that, but we still have some more. We've got about 10 minutes. So I wonder, are we ready to vote or give feedback? Is there something we should do with this one, given what we're seeing here? So thanks, Matt, for kicking off. That was going to be my question. It's based off of the discussion that we're having right now and some of the questions that are coming up around where it's currently at in its application, where we could see it going, and some of the considerations that are currently architected for it. This sounds like something that we'll need to assign a TOC member to go back to the project, ask some more questions, and then potentially revisit as a later date unless folks feel that it's at a position where we can make a decision. Matt, nodding his head to the first one. Kathy, you as well. Others? Yeah. Okay. Who wants to be the TOC member to communicate back to the project? Ricardo? Awesome. Thanks so much, Ricardo. All right. Sorry, Ricardo. I cannot hear you very clearly, so I may not understand your questions. All right. Moving on to Headlamp, it's a fully featured and extensible Kubernetes dashboard. They're specifically looking for a vendor-neutral home, but don't necessarily provide a lot of background or information where they're experiencing any challenges because they lack that. But I'm curious, what other folks feel about the project? It's relatively straightforward. There are existing Kubernetes UIs that exist within the ecosystem and even outside of the ecosystem. This one has a slightly different take on extensibility, though. Yeah, and if I remember, I think the Kubernetes dashboard also now has plugins to it. I haven't used it in a long time, but I think it has a plugin mechanism as well. Yeah, I feel the same way. I do not see what a lot of you know. What have you said it's going to have some UI, extensibility? I think the scope is small, I feel. Well, I don't know what is exactly the differentiation or the key values that it's going to add. Matt? I look at this and I think, okay, there's a number of dashboards out there. Some are proprietary. Some are, they've been making changes. It would be really nice to have one that's always going to be freely and totally open. We have a bit of that in the Kubernetes dashboard, but I haven't looked at that in a long time, but they did have some trouble getting enough contributors and things like that. I like that this is both a desktop app and you can run it as a server because people are really looking for that as a desktop app these days and having one that's totally free and open. I really like that, but they've also been around for a while and been somewhat successful. The thing that catches my attention is their interest in a vendor neutral home and are they looking for multiple vendors and people to start working on it there? That's the one big thing that catches to me that says maybe this does belong in the CNCF. I think this is generally the sentiment that a lot of the Kinvote projects are going to come to us with because they're in a situation where they are now part of Microsoft and so for their projects to continue to work in an open source environment, they're concerned that because it's a Microsoft project they're not going to be able to pull other people into it rather than if it were a CNCF project, the people behind Kinvote would push for would be more open to the idea. So I'm hearing a need definitely for Sandbox also hearing some questions around working within the space with the existing Kubernetes dashboard that's already there, making sure that we we have multiple options available within the ecosystem. How do folks feel? Is this something that we should go back to the project and ask more questions on it or is this more around ready to go to a vote? I was also thinking like since it's mainly Kubernetes based, why not just bring it in like Kubernetes 6 or something like that and work with the SIG UI folks. That's another good path. How do folks feel around that one? Lots of head nods? I don't know. In general, we seem to have the arrangement that they prefer things to come to CNCF mostly. So I think it kind of fits in CNCF. And it does provide the something we don't have with Kubernetes dashboard and that's a desktop app which we're seeing just a lot of interest in those kinds of things. So I'm hearing move to vote. Probably some still open questions around it. So that sound about right? Head nods? Okay. Amy, let's put the headlamp to a vote. Adding to a vote. Moving on. We got two more. I think we can do it. Cube Zoo, lightweight Kubernetes multi-tenancy gateway. This one looks like they're just looking at adoption. However, I do want to call out. They currently don't support anything beyond Kubernetes 124, which is end of life in July of this year. There's a lot of missing information in this. Anyone have strong feelings about moving it directly to a vote? I think we should probably ask questions around it, right? Like the reason for the CNCF is community adoption and contributions. I think there's a mismatch there. Then there's obviously the Kubernetes versions they don't support. I'm sure we've got other questions. We should probably ask them. Did we send them to a SIG, though, to get that answered? What more would they get from us besides we would be regurgitating the process that's already out there? This is obviously very anemic in terms of an application to try to convince us. I'm just, it seems... Well, so while I think they could benefit from someone working closely with them to provide more robust set of information, I think given the amount of time commitments that we already have and the level of effort that it would be to bring this up to an appropriate level of content for a proper application review, I don't know that it's worth our time or energy right now. How do others feel? It's interesting that they don't list their competition in this space. There are other projects doing this and that. I agree. I agree that it may not be worth the time. Okay. Amy, let's move... I'll take this one as like reapply with more details. It's fine. Cool. All right. Sounds good. All right. Last one that we have for today, SOPS. It's in the Secret Operations. It's an editor in the form of a command line tool in SDK for helping manage encrypted files in a variety of structured formats. Anyone want to take your first pass at this one? I can take your first pass at it. So, SOPS has been around for a number of years. I mean, it's used... It's a dependency for flux, which is probably why you see a WeWorks person on the application. And it's been maintained by Mozilla for years and years. And I think what they're looking for is to find a different vendor neutral home for it because Mozilla is not so much investing in these days. And there are people who want to, who aren't under Mozilla and they want that other home. I can't even remember how many years ago I started using this. I know it's been around for a while. We've used it in Helm. Flux uses it. So, it is mature and stable. Actually, seeing it at Sandbox is interesting because I think they're one of those ones that maybe I'm a pass-track to something like incubation once they figure out their governance and everything. They've got multiple people. So, it fits the vendor neutral home. So, for me, it looks like it's something that fits. Yep. I completely agree. I'll add on to that. However, their last release looks like May of 2022 and they're not doing any more active development based off of the information they have here and within their repository. Their contributions are on the decline and that might be because of where they're currently housed. They did make mention that they've been approached by CNCF maintainers and contributors through those projects that Matt called out. But I haven't, we haven't really seen anything happen as a result of those discussions, at least looking at the project's repository. So, it sounds like we really feel like they should be incubating but there might be some potential health and sustainability concerns associated with the project coming in. Anyone else? I mean, I think it is a relatively material project. I think there might be ways that people, I mean, I think certainly, I think there are ways in which people want to potentially take it in different directions but they might involve just using it to build something on top in CNCF and things like that rather than changing the direction of the project. It's a stable base and as Matt said, people have found it easy to adopt to use for things in CNCF now and that might be the best path as it's a stable substrate on which you build other things and that's, I think, fine. There is one thing that we probably need to address and that it is MPL version two on its license came out under Mozilla, makes sense and they have over a hundred contributors over time. So, what does the licensing mean to the CNCF as well? I think it's, you know, functionally bringing them into Sandbox and seeing if they can breathe light back into this, I'm good with. It's, there's licensing and things like that and I'm not sure how those all work out. Others concur with Matt's recommendation to move it to a vote? Some of the people also have decided maybe because of an incubation, given the adoption by so many in the search, there might be some things to clarify. If we move it to Sandbox, I think it would be pretty fast that they employ an incubation right off the people who just think they're sorted in. Okay. So, Amy, we'll move this one to a vote then. Sounds good. That wraps us up for today. All right. Thanks so much, everyone. I will see you all next week. Have a wonderful day. Thank you all.