 All right, welcome to September 12th sandbox review meeting with TOC and TAG chairs, Ricardo passing to you. Yeah, so welcome everyone so. Today we have 10 projects to to review 10 submissions to sandbox. You can get started already. The first one is copacetic copacetic. This is a tool to patch vulnerabilities in containers in kind of a special way for the patches are directly on container images. According to the vulnerabilities of tools like 3D. And I think the main feature is that they are patched without having to go through upstream and the full rebuild. And I don't know if anyone had a look into this project and has comments. I can start. So I spent a little bit of time going through this because I feel like we've talked about this one before or no I've seen that before. It is solving an existing problem that the, they talk about it either within the application or somewhere on one of the documentations or sites. Most organizations are having a lot of trouble keeping up with updates to production because they haven't quite streamlined their build pipeline to do deployments in a more automated fashion, particularly for security fixes. So it's nice in that it's solving that problem it can function as an SLI stop gap. My only concern and this is something that I think that the project is going to have to figure out how to strike this nice balance is how do we avoid codifying anti patterns because realistically, we want organizations to be improving their build pipeline so that they can automate their deployments in a much faster way. And this provides them a different mechanism for managing that. So I think that would be the only concern that I have I also noticed that while they currently support trivy they don't have any other scanners that I could come across within the repository that they're actively integrated with but they do have plans to support this. So there's a lot of RIF formats in the future, which most scanners I believe provide outputs into but it's unclear from the existing documentation that I was able to come across how all of that actually is intending to work together in the future. Right. There was also, there was a presentation to tax security. The recording is here I don't know if anyone attended that and has more feedback. They seem to be like, they know the problem space fairly well and I think that they're early in solving the problem but not too early. So I think they are a good candidate for experimentation within the ecosystem. All right. So, if no one has any more feedback, I guess we put it up for a vote. Is that correct? Sounds good. We do votes after the call so we do most of the discussions here and then Amy will graciously open everything at the end. But you tell me which ones you actually want to go on and this one you've told me you want to vote on. Well done. That's what I meant. Just open it up for a vote. Cool. Right. First is done. So the next one is the logging operator. So there is also something particular in here which is it seems to be managing more complex or targeting more complex configurations of inputs outputs for logs and routing. They have also presented presented to tag observability. Or they will present. I couldn't find that I actually checked in the agenda. And I put it here with clear, but I don't think there's any, any apart from the slides that are linked I couldn't find any kind of notes that might have been taken about it. I don't know if anyone has more information. Okay, I'm mixing up so there's actually some, some not this is just, yeah, I don't think that we had more notes about the presentation. Someone from all sort of villages here. And he thought some of this one. It seems pretty mature and well supported so. Seems quite. And as a lot of different integration seems quite, quite seems quite a good fit. Justin, I'm actually kind of curious why apply at sandbox instead of incubation since it's been around for a while and seems to have some adopters. All right. When I was looking, perhaps the question why not incubation. When I was looking at the contributions since like there is one main maintainer that kind of prevails for our time. We don't have so many contributions consistent contributions from other maintainers so hopefully. I'm wondering if I looked at the wrong repository. I might have looked at the repository please. This one looks like it's extensively. I think I looked at the sub sub repository I looked at the work directly and I clicked on a different repository so please ignore my comments. I mean it's possible they just didn't want to do the dd because it's a lot of work. So should we ask them if they would consider it. And then either if they really want to look for sandbox first we open it for a boat otherwise we suggest applying directly for incubation. I'm actually kind of inclined to push back a little bit from sandbox particularly for a project that appears to be as mature as this one is. We have a lot of projects in the sandbox ecosystem and based off of recent discussions we really want to promote more experimentation more innovation within sandbox. So if there's an opportunity for us to identify and recognize projects that are more mature, have they're a little bit further beyond. I'm curious whether or not we should start inviting them to apply it incubation so we can do a little bit more deep dive analysis on them. I think I agree with this. I think, you know, giving current is the worst of commentators. I think it's probably a better fit for sandbox projects. And then we can see how it goes. What does the number of contributors affect part of the air to pull it to incubation? I didn't get it. Sorry. It was breaking up a bit. Sorry, I'm not fortunately driving but I was asking, does the number of contributors affect our desire to pull them in to incubation. From the repo, it sounds like it now. But this is something perhaps we can help them with for the incubation. I think they definitely have potential. So this is something that we can list as criteria where they can go through the criteria and they need any extra support or anything from the to see where the tax would be able to help them for us. As mentioned, I think this is definitely a good candidate to move a level higher. I think, yeah, we definitely can suggest that it's up to them to to push through the processes course. Yeah, I was going to say that some of these projects or project maintainers don't know the whole process. So the first thing that might have seen it just sandbox, but I mean, we can actually communicate with them and let them know what the process is and guide them through if they want to go for incubation. All right, so Chris also had left a thought that maybe they are just applying for sandbox to understand better how an open source project can go bigger. But I guess the way we suggest that they apply for incubation for now. Are we are we saying no we're not going to vote on sandbox we're going to ask them to apply for incubation instead, or are we going to say let's vote on sandbox and ask them to apply for incubation right away. Oh, that's a good question using the sandbox queue to allow them to go through all the onboarding that way it makes that incubation due diligence process a little bit easier. I think that's a good idea. I mean probably you're also the best team. Okay. Yes, add them to a vote so that because like I know we're interested in being able to clear the cues. If we say, hey look, we think you're actually like ready for incubation. Let's put it up to a vote. If it passes will work through them with onboarding and kind of give them a sense about like what incubation means for them. And then they can decide whether or not they want to apply. Sounds like a good. Good. We can move on. All right, so the next one is cracking. So this is a chaos and release resilience testing tool for Kubernetes focusing on evaluating performance and their loads and that scale. That's, there's a nice picture here of how this works. I have seen this project in the past as well. I believe they also. I know in this case they did not present yet, but I think there was a suggestion here to go for it. Any minute thoughts on this one. There's a nice picture here of how they integrate the different guys. So is this all the repose under red hat chaos. Yeah, they should be all in that namespace. Oh, is it all of them? I think we've, I'm not sure if we're, we tried to make that question less confusing, but we put org repo URL, but. Right. It's not, it's not really clear to me which is it, whether it's. They don't link an additional repo, which is a different. I don't. Yeah, I don't see anything in this GitHub org that would not be considered part of breaking that would be donated. It looks like they already took out anything that was like tied to red hat products. So looking at the form that we put together for this. The project repo URL is supposed to be in scope of the application and the additional repose in scope of the application. So that's the additional repose area. The org repo URL is provide the review, the URL of the GitHub or GitHub organization of the projects if all repose under the order and scope of the application. If no organization provide any so it sounds like we can clean that up to make it a little bit more clear. Just looking at the way we have the instructions written. It sounds like cracking and server is the only two that would be in scope, but we should clarify with the project. Do they have any additional ones that would not be in scope. I think that's those just in question. Well, well, I just wish. In that case, I think it's everything because they're either about cracking or several sort of the other ones. I know there's other things as well. No, I don't know. I'm looking over this everything in that GitHub org is either cracking or server is or or a dependency like GitHub actions for, you know, the manage services deploy. That's actually a deployment thing. That's the one thing that it's actually probably the only thing that you know why they left that in there because right now it's only open shift. So that would be one that you want to ask the project. Hey, is this going to support core Kubernetes or are you going to take it out? It's just a set of playbooks set of ansible playbooks. So it doesn't seem to be very active either. Yeah, and it either could be something that they left in there because they're planning on making it support core Kubernetes but they haven't finished yet. Or it's something that was left in there by mistake when they were actually cleaning it up to separate out, you know, just the things that were being contributed. I just have to ask. Yeah, and apart from the repos and the org. Does this sound like something we would say for a vote. Go ahead. Um, so I'm wondering whether they have presented this to the Kubernetes community to those six. Because I see that, you know, there are some scenarios on Kubernetes scenario, they do not support like the pop network scenarios. But they support that in the open shift. So it's more targeted towards open shift. I would like to know what is a community is community feedback on this product. You know how useful it is. And also how good these are, like it's a design. Right, so I don't, I don't, from, from the, from what is here, I don't think they have. But I'm not completely sure. Maybe we can ask them to get some present to the communities community and give some feedback. So we can, you know, better evaluate this. Because there are other quite some, you know, also resilient resilience testing tool testing mechanisms. We can take this on the delivery side to have them present. I think they did not yet present and there's also still the dedicated chaos working group. That wasn't what Josh was proposing. But let's ask them to present there and we will then share feedback after we have the recording. So always you will, you will drop them message here in the, yes, I will. I'll take this one. All right. So you can find me a relative notes. So we can move to the next one, which is canister. So, as far as I understand, this is quite known as a project. It's focusing on data protection or in at least my knowledge is more on the backup and recovery side of things. It's very similar to projects like Valero as well. One thing that I would highlight is that they mentioned here some presentations so they actually mentioned a presentation from a colleague of mine so we know this project quite well, and yeah they describe it as the, it's the what the rest of us with Valero. They have similar tools that don't do what Valero is doing is to the same space. So I see Kathy, you have to hand up. Sorry, Emily go ahead. So I had a question about this one. Is it really data protection, or is it more data management with some security features added in. That's what I couldn't get specific clarification on when I was going over the project documentation. It seems like it's primarily proper data management with a little bit of some of those features sprinkled and but not specifically focused on data protection and cloud architectures. So abuse canister before. And the best way of describing it is, it's it's provides workflows for different stateful workloads to allow you to do things like creating databases and things like that before you actually do snapshots and backups so it's not actually the it's not actually the backup tool. It's the tool that you use with your backup tool to safely backup your databases kind of thing. It's for more complex backups. So you're unmuted. Right, so we use it as exactly that to define policies for backup and restore based on PDCs and automating that and then the actual backup tool and copy is using this copy tool. I don't remember exactly if Copia is part of canister or if it's just using it underneath. Copia is another open source project that I need to be using. Active allow is also using Copia now so. Right, yeah. So I think it's in the same space as Valero. Yeah. Yeah, that's why I asked them to put together the comparison table that'll be helpful. I mean, in general, I do think this is a great candidate to be a sandbox project in CNCF. I just there are some comments that I still want them to address but but it's, I do not have objections for them to become a sandbox project. I do know it's used in production and a number of large organizations. Okay, so it seems like it goes for a vote as well. Yeah, we'll take that and we can move on. Right, the next one is KCP, which is for managing control planes of coordinates clusters, I guess. And they mentioned also management of applications. Other parts of the infrastructure and specifically. It used to be like a sort of API, building on coordinates API student to manage additional things that are not just contains. I'm going to check again if there was. Okay, there's quite a lot of follow up here. Let's check. There was. Sorry. KCP is actually a multi cluster solution. It's a way of maintaining a meta cluster that controls other Kubernetes clusters. The CP stands for control plane. It does this somehow using CRDs. I did attend Stefan's presentation on it but I don't really understand the architecture. But but that is the intent of the tool. And it's had this point over a year of development. Possibly a little bit more than that. The actually probably closer to two years of development so. Yeah. Yeah, I see that it is like, it's part of it, virtualize the control plan. I'm not just virtualize, you know, the, the OS or the, the resources, it virtualize the Kubernetes control plan. And then it provides, you know, across, like, you know, Josh said, you know, multi cluster management, but it's logical clusters, not really physical clusters. Yeah, it's logical clusters. I think it's interesting. But I, but it didn't say very clearly, what is the, you know, the benefit of this, you know, compare with other solutions, because there are other solutions that's doing, you know, across logic logical clusters management. So that's very clear. As I understand that the goal of KCP was to be a little bit more tightly integrated with Kubernetes mechanisms. That is to, to work through aggregated APIs and the CRD mechanism in order to supply multi cluster functionality, rather than doing so through a more external tool like OCM or cross play. I haven't seen a detailed comparison either. Stefan's presentation did not really compare it to others. So I think Ricardo, you have to hand raise as well. Yeah, they had our presentation in tag runtime and the project is pretty extensive. Yeah, I think the control plane is actually meant to manage other things than, I mean, besides Kubernetes, they can manage other things. But I think that's more on the roadmap. It's not quite there. So right now, I think the basic example is managing Kubernetes clusters. But then they're using Kubernetes resources on top of that. And I think longer term goal is also to manage some other resources that are not necessarily part of Kubernetes. So you can manage things like nodes or other types of clusters or other types of cloud native resources, but that's not actually implemented yet as far as I know. But yeah, it is pretty extensive. Mainly backed by VMware or maintainers are part of VMware. So I mean for sandbox is okay, but I mean something that in the future, they might want to look for maintain your diversity if they want to go for like incubation or further. Emily. So, completely agree with everything that Ricardo said, it definitely sounds like the project has a lot of high aspirations for making, giving that Kubernetes like experience in other infrastructure. The key call that I want to mention here and I don't know that we necessarily talked about it is they do have a slight focus on multi tenancy, which we don't have a ton of projects that create a framework for multi tenancy to be done by organizations or even service providers in a comprehensive fashion. So this would be one of those new additions. And in particular, if the project can pull off being that control plane across multiple different workspaces environments to give that Kubernetes like experience, we could potentially see more adoption of cloud native technologies outside of traditional Kubernetes deployments. It might be also in the area of other projects like Carpenter that was practically multi cluster and management spaces as well and the target clusters. Yep. So I think we open about this one. Is that correct. Amy. I think so, Josh has a comment and I don't think I'm finished. There we go. Okay. Well, I can actually say just you know for history this. This was originally a red hat project. And the main work on it has moved elsewhere. And that's one of the reasons for applying to the CNC office that they really wanted to be owned by the foundation because I think there might still be pieces of it that that red hat owns in a legal sense which we will of course donate. The, but putting my red hat hospital hat on instead of my tax CS hat. The, but just so that you know the history there. It's reasonable. Thank you. So the next one is was mock server and I'll just open the repo because this doesn't look like it's, I don't know if you went a bit deeper but this looks like a bit early. Hi, I realize I'm talking a lot here, but the maintainer of this project maintainer singular. I was at wasm con last week. And I met with him. It's a desktop testing tool for wasm for WebAssembly server site though. The body does have just the single maintainer. And just nine commits. Yeah, I think I think in the past for this kind of projects we gave a message to try to build at least a minimal community and then come back. I mean, based on meeting with him I think that would be reasonable. He's basically a QE who built this tool for his own use. And it's, you know, looking for a home for it because it's not his main job to maintain this tool. I think this might be a good candidate to shift over into the wasm working group. Yeah, that's exactly where I was going. I would recommend still too early. Definitely worth getting them connected with the wasm working group because I think that there are a lot of interested individuals who might find this useful. And potentially help drive some of the contributions that way and then once they get a little bit more mature and robust and have been around longer pre applying at a later date. I think they did. I'm close to the link there. Go ahead. Yeah, they did present to the wasm working group. They are connected, which I think is great. It's early stages. This is it like, I know it needs a home, but perhaps just being open source and inviting contributors might be first step, and then perhaps they can come back. I do appreciate the project being very ambitious early days. I think that's a very good kind of mindset to approach CNCF and understand the processes and be part of Sunbox. But hopefully they'll grow a bit more within the next couple of months. Sounds good. So, thanks Amy, one of the next one. So that's Kubian. It's pronounced like this. And yeah, so this is also on the management of additional coordinates clusters but relying on a coupe spray. And the same area of what we mentioned earlier with this be, I guess, I will just check because I don't know if they really presented. So any comments. So they did present in tag runtime. I think it's good for incubation, fairly mature for that for that level. So from KCP where KCP is more like a control plane at a higher level. Kubian is more of a cluster deployment creation tool. So it actually creates Kubernetes clusters and or a fleet of Kubernetes clusters and it helps manage them. They'd rely heavily on cube spray, which is another open source project. Sure. Other comments. Is there any reason why it couldn't be a cube spray project rather than independent project if it's so tightly coupled? Well, right now they say that they support only cube spray but maybe in the future they might support something else. But I mean it's something that we can bring up to them. They might be good to just work with the cube spray community instead of having something separate if they're only going to support cube spray. But yeah, so that question actually came up in the meeting and they said that they only support cube spray at the moment. All right, so there are some value added in the sense that they actually manage the deployment of the remote clusters. There is some overlap with other projects that manage control plane like KCP and Carmada. And there is a question here asking if we can compare this to cluster API, which has a few extensive answer here. So what's the suggestion here? We go back and ask them to contact cube spray and try to clarify this or we suggest that for a vote. Yeah, I think it might be a good idea to go back and ask them whether they're going to support something else rather than cube spray. And if not, then open it up to see if they want to work with their community. But yeah, I mean, it's also open to what other folks suggestions have here too. I think it's entirely reasonable to send them back to have a meaningful discussion with cube spray to understand a little bit more about whether or not they should be homed with them and that they align really well and they're just another capability within that project, or if they're pointing on supporting more beyond that because once they once they branch out of just cube spray, then I think it's more applicable to a lot more adopters. Okay, so we asked them to clarify that, to ensure the contact group spray and discuss this a bit further, and then come back to us. What question, does anybody know if cube spray is a CSF project or is it under the Kubernetes community or I'm not really sure. It's under Kubernetes. Okay, so it's already working. Yeah, with the Kubernetes community so someone one option is just to go back to work with the Kubernetes community together with cube spray sounds reasonable. Okay. Okay, so we move to the next one, which is KCL, which is subscription is constraint based record and functional language and tools primarily utilized in cloud native configurations and policies scenarios. We can completely get what the goal here was so feel free to jump in, but it seems to be like some sort of abstraction language for defining these policies and relationships. Well, it's a DCL for managing Kubernetes clusters kind of like ballerina is if you know that commercial product. Yeah, is it kind of like Pulumi or something or ballerina is it's kind of like a line. Yeah, although Pulumi goes well beyond Kubernetes clusters so the is like Pulumi is a got a management language for all kinds of things. The DCL is strictly Kubernetes clusters. Well, Kubernetes and a few other tools like Argo, but things on top of Kubernetes. It seems to be significant activity and support. And I'm not sure from from what you were saying it doesn't seem like there are many projects in this area. Is that correct Josh. I don't know. I haven't really looked for them. And also, they've presented that tag in August is Nikita here I wanted to thank her for bringing basically know the tickets asking for presentations that this seems to be very effective. And the conclusion from seems to be that it's a good fix fit for CSCF sandbox, so I guess, good, good recommendation here. You open for all right. After them for a vote moving on. So there's a question from Leo about when should projects like this be put on the Kubernetes or since yeah. Anyone wants something. I think it depends. Unfortunately, like that's the short answer. It really depends on the project would it's trying to accomplish whether or not it's a supporting mechanism for Kubernetes or whether or not it's like its own independent project and I think that is like, and to Josh's point, he doesn't accept it so it's unfortunately kind of do this weird back and forth with some projects and trying to figure out where they go but it's really dependent on their scope and what it is that they're trying to accomplish. Yeah. There's also left a comment saying part of the question is if governance would actually accept it. So, but I see Cassie and Ricardo are in YouTube. Yeah. So, um, I think this part is the goal is to simplify some configurations and some APIs for managing the communities. So there, you know, there are other projects try to do this so I don't know whether it's surely I haven't done into detail how good it is, has this been presented to any pack or and, or to the Kubernetes API seek, you know, so that they know, yeah, that whether this is a, you know, the design is good, or how useful it is, my question basically is right, looks like it's trying to abstract to more, I mean, have more abstraction away from the infrastructure and provide more and lower, you know, configuration APIs to do that. I think the goal is to try to simplify that on those things, but how good it is. I think we have two options here either. There's a recommendation here from the tag to include it in the sandbox. And there's also the possibility of asking them to contact coordinates first to clarify if this is fits in the abstract. I think some feedback from the communities. I mean, I think it would be good. Yeah, sounds good to me. I think there's also a little bit of overlap with the open here, open policy agent. So maybe how I mean, because he talks about policies right so and how to manage policies so that a good question will be how different it is from that or is it the same or is it just for Kubernetes or is it trying to do more besides Kubernetes like none, you know, like other types of policies, maybe policies for cloud native environments. All right, so. I've just also left a comment about for the Kubernetes is not going to take it as a sub project so maybe we open for a vote and leave out anyway, note that they should reach out to parties to clarify this in any case, does that sound reasonable. What do we want to be able to clarify. If this is a fit as a company is a project or not. If we've already opened them for a vote for a sample project, I think we leave it there. Okay, so we open for a vote. Okay, open for a vote. We'll see what happens. Time check, we've got 15 minutes moving on. We only have to left should be okay. So coordinator, it says it's a quality of service. The scheduling system bringing optimal layout and status to work with such as microservice web services and big data jobs so in this case actually, well, having a look. It did feel like there's a lot of overlap with the scheduling scheduler of Kubernetes. Although it introduces notions like quality of service. So it is interesting. If I go down. I don't think they is. Did this actually happen Ricardo in time to presentation. No, I haven't have it yet. Yeah. Oh wait, that's coordinator. Yeah. Yeah, yeah, it has it has but I wasn't able to do yeah to join that meeting but Well, you can take a look at the notes and see if we have any. Yeah, I checked before also you couldn't see. Any left. So I don't know if anyone managed to attend. Yeah, I went through their, you know, their webpage and the functionality. I think they will provide some isolations for to solve some noisy neighbor problems. You know, they, I think they are the other projects that are doing this. I think it's good to ask them to consolidate with other work streams in this area. And then come back to, I mean, to present to come back again. Well, my question here is, is why isn't this in the Kubernetes schedule. I don't know if they replied in some place I couldn't find it though. That's a good question too. I think because it's closer related to, you know, the resource scheduling. Yes, my suggestion is just to go back and talk to the batch initiative initiative system working group that we have another tag runtime and also work with the batch workload community so and then and then come back and see how they can work together with them. And Ricardo, can you put the exact name of that in the chat. I know, I know there's a bunch of different names for it and I want to be clear about like which one it actually is thank you. The group. Yeah, the bash working group. Yeah. So that's words please. Yeah, so there's the best to them where to go. Yeah, so there's the batch system initiative working group that Ricardo just based it there. And then there's the Kubernetes batch working group that is part of six. That's stolen. Yeah, there's also a community six schedule. There's a close related to that. So they can present there to start with tag runtime because it's always best to be able to give them one. Happy to be able to have more comments on the issue as well. So. Okay, so, but I guess the decision is to pass them these contacts and ask to come back with more clarifications later. And the last one we have this chaos. This is a meta Linux distribution to build immutable edge Kubernetes. And from my quick check with the project, this seems to be relying on the kids to build those images for for this different environments. Yeah, quickly on. Yeah, this we have a presentation on Thursday and tag runtime, so we haven't presented yet. So should they move it to the next one after they've presented at that runtime. It's unreasonable. I think I would like the recommendation from the tag before moving this into about that this has a lot of interesting opportunities but I think having that domain deep dive would be beneficial. Yeah. Sounds good. Also, this, this part is to build another immutable Linux distribution. Is that remix layer or in this OS be part of the. Do we have any party practice, which is like a Linux distribution. There's, there's a whole space behind these special purpose operating systems. So we also we've have also created a special purpose operating system working group so that the possibility is also open to work with that working group. But yeah, so there's other projects in that space like flat car and tallows and. I think there's some some other specific Linux distributions that. The overlap of this. And there's one specific to the edge, right? So, but I think it might be a good idea to hear what they have to say in a presentation. Yeah. Okay, sounds great. Thank you. It can also be beneficial to have the project present or invite some of the tag security members over to the project presentation and tag runtime. There are some zero touch. Zero trust kind of concepts that are being integrated within the project based off of some of their right papers I haven't read through them all but good idea probably to cross pollinate between the two tags on this project. That was good. We'll, we'll advertise and the tax security slack channel. Thanks. And I think that's it. We're done. Thank you very much.