 The first one, all right, we are recording. Welcome in. This is your sandbox project for. Tuesday, September 13, ready to go dims. Yes. Hi, everybody. So let's start with a resubmission. I think this was the only one which was a resubmission. They ended up going to the serverless working group. And this, the project name is serverless devs. Did anybody get a chance to look at this one? I took a brief look at it. I noticed that it's MIT licensed. And I was trying to figure out the reason, but was the field cut off in here. Yeah, everything I can't really use. Oh, let me see it. Really use the reason. Okay. Because I was trying to understand the reason and they put a bunch of stuff beforehand. If you scroll up dims, there's a link to the English version there. Oh, you scroll past it. Oops. Scroll past it the other way. Right after the header. There you go. Yeah, it took me a minute to. My T. Yes. I only got the briefest of looks at this because it was further down and I started at the top. It was one of the later ones that I got to. Yeah. But it looks to be some kind of serverless framework, but I couldn't exactly tell why they wanted it to be in the CNC F. To understand that. And then there was the MIT license that caught my attention. Yeah, the MIT license is okay. We can, we can do contingency based on you changing license. I think what they are trying to do here is, you know, you are a normal application developer, you have some serverless code, you want to run it. You know, you want to run it somewhere, right? Like you can pick where you want to run it. You know, you can generate a template based on, you know, different languages. So it's like a menu driven thing, and it'll generate a bunch of stuff that will help you deploy to one of these serverless runtimes. So it tries to make it easy for people who are starting their serverless journey. And that is what I got out of it. I would agree with that. It's focused really more on the developer experience, but it's also heavily focused on serverless deployments to third party cloud. There is, I believe, some documentation around open function compatibility, but it's not very robust or in depth, at least that I was able to come across. I mean, the project is two years old, pretty steady piece of development. Nothing that kind of stands out as being potentially problematic or hindering, but I think the question comes in since they've already presented to the serverless working group. And this is a reapplication how they fit within cloud native. Yeah, I think, I think I want to like help them by bringing them on for sure. The other one that triggers also is like, hey, does a service, so less working group. Do they need to be sick at this point because there's lots of projects already so that's a different conversation. We can have it with them. But for the purposes here, I feel okay with. Did you already fix it? Amy, I still can't see stuff. Yeah, refresh. What I've done here is make sure that everything is wrapping. So you should be able to actually get in here. Let's go left to right. We thought this one. No, something not screwed. Website URL. We already went through the website project roadmap. They do have something they're already code of conduct. IP policy. Okay, yeah, this, this is the one that will help us relate to existing stuff. So open function. Yeah, they are so they know what else is there. They are in the process of working with other people, which makes me definitely feel better. Oops, this one can see I can't do this. We've just covered a fundamental limitation of giggle shades. Yeah, exactly. In case we find them all the time. Okay. Now, and this is from Ali Baba, right? So, okay, so any objections, right? Like, is there anything that you see here? Okay, so Amy, let's call for a word. All right, vote is open. Scrolling back to the top container SSH. There's another reapplication. They've not called it outline 12. This is CubeScape. So if we can grab that one next. CubeScape. Okay. Thank you. CubeScape. So open source tooling, providing a single pane of glass for Kubernetes security. NSACSA, MITRE, RBAC, CICD pipelines. Anybody? Sorry, sorry, sorry, sorry, is this a reapplication? Yes. Yeah, so what did we, I can't remember what we asked them to do last time. I do remember. What did we ask them to, why did we ask them to come back? I believe we asked them to come back due to a lack of clarity in the project in the direction and I know that we asked them to present to tag security. So the maintainer reached out to me to verify that they did everything that we asked them to do. They have, they presented a tag security, they've gotten better vision and direction to move forward and they're working on their community growth and development. I think they're in a really good place to continue to move forward. How do they, how do they do what they do? Do you know, Emily? I do not know offhand. It's been a couple of months since I talked to them. So they scan nodes, they scan YAML files was as far as I got. And, you know, they'll tell you if something is not right. Scan YAML files. Okay, they support air gap. So they have a CLI and SAS. So you can control all the things that you can scan. Where do you NSA scan NSA stuff? Single pane of glass risk analysis, security compliance, RBAC visualizer and image vulnerability scanning. And they support all the CACD stuff. And did you figure out this? Yes. Yeah, I have a minute. Yeah. Armo and Cubescape, right? Armo. Cubescape. Yeah. So it's probably a startup. That is behind this. Yes, it is. And I had some conversations with them. Because there's also a SAS service that it submits to. Yeah. Which was very unclear how much of it was open source and how it was related to the project and what the boundaries were at the time. So do you have any concerns about? Yeah, so my concern is that the SAS service to which it submits your results is not open source. And it's also called Cubescape. Oh, Cubescape, okay. Yeah. So as far as I can, this is not open source service. It communicates to a private SAS service and the boundaries between that service and the project and not at all clear. So I will say, going through their documentation, they do have instructions on running it offline in a air-gapped environment. Okay. So they're probably building, they're using the engine in their service also, I guess. Is the default, if you don't do anything, automatically just work with their SAS? So, I don't know the answer. No, I believe that it doesn't. So just getting. I believe it works offline by default. And you have to do submit, but it doesn't have a way to. So you have to do minus one and submit on the command line. There's no configuration as to who you want to submit to other services or anything like this. It's basically submit results that keeps get SAS version. Is the version that you self-host? Does anybody know if that's open source or is that a proprietary software you then self run in your offline environment? I can't. What's the role of this organization? I mean, a CLI that's tightly coupled to a startup SAS. Isn't something we should probably have in this, this CNCF. Yep. Right. Because then that plays up one vendor over others in an open source project. Right. So let's ask the specific question and get the answer. And based on the answer. this being a standalone thing that can be installed in somewhere, they do cover that, right? But it has like 70 over 70 contributors, so it cannot just be their own sass, I guess. Yeah, exactly. I mean, it works without the sass. So that's a different. So what's without a sass implies that anybody can set up CubeScape in their environment. And they can use the CLI tool to submit to their own CubeScape instance. No, they can use it to run locally. I don't know if they can submit it to their own instance, but they can run the checks locally and get a report out. Which is not as far as I can understand that the sass is just collecting the data from these reports. So it's coupled to a sass to submit reports to, but there's no methodology to run the software of the sass yourself. That's not being submitted. And they have no means to submit a request for other sass as you could submit it to. I didn't hear all of the calls because I watched that video in chat. At least here you see that you can have local results, but I don't know if you can persist them in any way or analyze them in the air gap environment. Persisting the output of that within the cluster is on their roadmap under planning. It's the first thing. Okay, so what can we tell them? What we can tell them is, hey, the people should be able to run CubeScape in their environments, Kubernetes environments, Conformant, Kubernetes environments. And the CLI should be able to, they should be able to submit whatever they need to submit to the local instance and decouple their specific sass out of this equation. That's what we can tell them, right? As phrase that wouldn't require any open source server or persistent component. Yeah, without needing their sass, people should be able to do what they want to do. Reframing this as a positive statement, we want them to allow people to run an open source version of their sass locally. Yep. There should be no coupling to a proprietary sass, yeah. And the naming would have to be resolved because the sass and the project about have the same name. Okay, so that's three things we are calling out between the three folks just now. Do you want to write this down, Amy? Got a note in chat better decoupling from sass as a requirement for onboarding or are we actually at the point of not letting them in due to this? It's almost like asking a question. I don't know. Well, that's why I'm like that. I think we need to be more clear here. Yeah. So decouple their sass from the open source project, which implies that the running the whole staff including the person needs to be possible with local open source. Yes. What are the other things that we told just now? Okay, I will take Richard. And naming. I mean, we have dealt with naming up to this case where the projects called kubescape, kubescape, and the sass is from kubescape. I've just got to deal with that. So naming issues and okay. It doesn't sound like we are ready for a vote on this one then. So decouple sass from the open source pieces, right? Okay. Naming and functionality. I don't know that because they're going to reach back out once they have that complete. Are we waiting again for another sandbox review before accepting or is a check in with the TOC in the main channel sufficient. We should wait. We have invited. We don't have good ways to be able to onboard like in out of band. And we have invited. So we can't accept. Okay, so. Is this going to be a question or is this. How are we framing this, Richie? Are we asking for like, okay, can you confirm that you can run the whole stack locally. No, we're pretty sure you can't. I mean, I mean, I think that I mean they could come back and say, you know, the distance of the doors is a separate bit of functionality. This is kind of, this is effectively open core and that bits separate, but I don't think we would accept projects that don't have neutral providers of these services that, you know, you can, what submit goes to their service, not the service that you configure. There's a spec for the, and ideally, so it's going for some, right, some tooling for collecting or something that some other ways that you can do if that function is truly useful. Okay, so we need to ask them to watch the video to hear me. Okay, I think we should move on based on time. Yes. Okay, here. Let's start from the top container SSH creates a new container. It's useful for several things, debugging production systems running honeypots. I can get, I can give some info here. We actually have a deployment at CERN of this and it was just to see if it works. They presented that the CNCS research is a group. And after the presentation, there was a suggestion to submit it for, for sandbox. There's the model that they want is to hide the handling of containers from most scientific communities where people are used to SSH to central machines where everything is installed for them. And it's kind of a niche project. There's not a lot of contributors. It's and there's something to be checked, which is it's an MIT zero license. So we also need to check that. But yeah, so it's, it's, it is an issue. I think it was remaining. At least parts of it have just been re-licensed to Apache with the lab container SSH is now Apache. We also have some funny like branding link. I'll paste it here. I don't know exactly. There's like a branding license. I don't know what that means. And I'll paste the link for the presentation. Yeah. Yeah, this is fine. We, when we are working through this, whatever they have here will get reworked with whatever we do for CNCS projects. I do not have any objections. It's a tool that seems to seems to be working. It's, I mean, I think one thing is, it's very small, although it has 44 repos in the GitHub org. It's got very little, it's not a lot of code. And it's not been around for a long time. I have a lot of contributions or stars or any of the other metrics. It's like, it's, I mean, this is a very small tool. So like, we, I imagine it becoming a graduated project ever. She's not to say it's not useful too, but we have had this discussion about some things about just being very small. Yeah. And, and like, small things are cool. I disagree, but it's just like, is it big enough to be a thing? I don't know. That's what we're telling them to do, right? Like do come into the sandbox and figure it out. If they make it to incubation, you know, then we'll worry about the graduation, right? So this project, when I went through the documentation has a lot of really positive potential associated with it from operational workflows and administration of production environments as well as some potential significant security concerns over the execution of it, particularly around default behavior. There are organizations and companies that have traditional production level management of their clusters where you have folks that are logging into prod environments, logging directly into containers to make changes on the fly instead of promoting better immutability with container images in their clusters. So this is kind of set up to assist in offloading some of that behavior into a more isolated container. There's value there in organizations that already have those and getting them to change those processes. However, because it is a container that you're allowing someone to SSH into, those ports are open. There are potential additional concerns. So generally speaking, I see the value in this. I'd be interested in seeing what the project does, but I would weigh heavily that they really need heavy security involvement from whatever their default configurations are and the overall behavior of the container within a cluster. Yeah, it also supports usage as a honeypot, which is fair in this case, which is kind of confusing from the configuration point of view because configurations are somewhat different. It's like they have separate quick starts for Docker and Q and it is so that's good. Yeah, I'm happy to let them in. I think there is enough value out here that other. I give an end user feedback from research communities. This is what our users have been asking for for a long time. That's the main reason we looked into it. Okay, whether it's, but yeah, but it's it is, I don't know, I think Emily expressed much better. Yeah. Okay, so any other objections other than what we already talked about. We can go for a vote. I would rather have them close to us so we can ask them to do more security stuff. Hearing no strong objections vote is open. I am pushing you all in the interest of time. Yes. I can't be using me directly rather than the group but passes. Thank you. Moving on. Okay, open FGA. This is something interesting. Anybody read the Zanzibar paper. Yes, a while back. Okay. So essentially what they're doing here is implementing the what's in the paper and who's it from. Okay, that's the start up. It's the author provider. Yeah, then all the stars up anymore. They're big grown up stuff. Yeah. It seems to be from off zero, which I think is a subset of octa. Yeah, I'll go required also. Yeah, see there right there a project sponsored by octa slash. I think one of the things that I read was like they will store all the things that they use that that is in the policy. So it's easier to look up. Rather than running the query every time you need to run it. You know, I, I took a look over this and I saw it got multiple repos SDKs a contributor guy there's a bunch of stuff going on here. The thing that caught my attention though was that it was started in June of this year I think. And so it's pretty fresh. That was the only thing that I really noticed that made me go, wait a minute. Let me take a deeper look and then I only got so far. Yeah, anybody else notice anything else. Maybe because, you know, they might have this in their existing code base and they are taking it out and they started it once the merger happened or something. I don't know. Just guessing. So, yeah, this is what I was doing simply query as needed is a database for relationship that go and access to resources. You have to load the data into runtime and to evaluate a policy. So I've inclined that this is a positive thing we should encourage people to get involved with earlier rather than later so I'm even though it's recent it's a, you know, it's a clearly a serious project from them and they've got a serious model that they're trying to implement and a model of how they're going to do it. Which is already a project and so on. Even though it's recent I don't have a kind of recency bias and recency bias whatever you got. Much about this as I would with some other things. Let's go work then. I think we have enough confidence here. One concern. Before we want one concern and I know that I think Emily mentioned this in the DOC channel as well. So as to why this is so new. This is forked from from a different company actually. And that doesn't inspire great long term strategy or anything, at least as of now there's there's a smell of little bit of smash and grab to be honest. I don't claim to have the full background on this but when looking into it because someone poked me about it. It didn't inspire confidence at all. There is enough confidence for sandbox, but not incubation right so let's get it in. What's it for is it sorry it's not visibly wasn't clear on the repair. Yeah, it's not. At least last I looked no attributions have been have been given the thing you want to look at this for is spiced to be from offset. That's where part of the inspiration was coming from. Did you say offset. I linked it in chat. So are they using it here or are they also sorry. Okay, let me let me give a little bit more background. It was created by someone who also worked on spice to be in the past and they, they were concerned about over over basically forking their stuff without any attribution, and then submitting it to to CNCF which has an good smell to it. In particular, unless we see octa actually carried us forward. This now, I remember both of us looked at it. This spice DB. Yes. So, yeah. So here is what they're talking about right. Yeah. largely inspired by graph and dispatch packages in odd Z, odd Z slash device device DB. And it's Apache to license. So, they're free to do that. Attributions, I think we talked about it and I opened this issue for attributions. So during sandbox, we can work with them on making sure that the attribution are, you know, better than what it is right now. I remember the conversation now. Given the time since they since they got started from the fork and I agree that Apache to allows for King is explicitly designed to allow for King in any and all other licenses. Still looking at the project as of itself. After the point of fork is a super short history. There's no strong history of contributions or community building or anything, because it's literally a new thing. I agree with you. I would like to do better now in sandbox under our guidance, rather than telling them to go away. I think we need to make sure we're hearing to the, the bar that we expect out of that I think is what them saying is like, it might not be perfect but it's also sandbox so you know when we go to incubation we can certainly list this is concerning that needs to be fixed prior to their application. Okay, so let's go back to the vote. You know, please do a plus zero or a minus zero. If you feel strong. So I cannot do it. Can I just give me another minute. Yeah. Just. Oh, okay, so I will not count your vote. Okay. That's fine. 10 more seconds. You can't do contingent votes on me. It's either plus or minus like I love you but I cannot track that there's not a thing. I'm so I was just looking at the, I mean, I was just reading through the initial commit of this is a working version and trying to see if it seemed. I mean, I think it's fine. I think it's, you know, these are both implementations of Zanzibar, both derived from something else, anyway, and we're not thinking makers about like that. I think that and it's, I mean, I think that yes, it's got a horrible chunky initial commit, but it's not all copied from. It's supposed to be by any means so. Yeah, I'm okay with it. Okay, so keep the previous vote. Okay passes and we can move on. Okay, thank you. How much time we have we have 19 minutes. So curate. So this is from the works. And this is for restarting the nodes so that, you know, you can apply some patches. We want to try to keep curate boring and reliable. So for better discovery by communities users. Yeah, if I look at this this was started back all the way in 2017, and has been developed consistently for a long time, and I think it was originally a we've worked project and then others started picking it up and using it. Yeah. So I think that that is probably why they're bringing it out now because there's just it's being used and there's a lot of people who contributed to it. I had a question about this one with there's so given that there's so much work that's been done on this particular project was there any consideration for including it as a Kubernetes sub project. Say no, for sure. Emily, that is the reason they are here. So I would you say no just just to get your current status. Yeah, it is just like we. The focus is on the smallest set of bits that go out as a Kubernetes release right. And we do have a lot of repositories that are don't end up in in the release for sure. But those are all small tiny stuff. You could feel free to send them across December. Yes, yes, absolutely. For example, right, like, yeah, many key box. Yeah. So you could could easily be a successful standalone CNCF project. It's only there for historic reasons. Right, right. So there's quite a few like that and we should go back and visit it. I'll take and make a note of it. Okay. So, do we call for a word, anybody object. The only comment I have is that it seems to be a one go file. Like, large one. This seems to be more here is reasonable churn going on over time. They work on your QCS. That's funny. Yeah, I think it's okay. They might expand out of this specific use case, you know, when they come in. Okay. Plus one dealt with six of them now. Okay, car well. This is from VMware. That kind of says, hey, Helm is not the only thing out there. There is a few other patterns that might be better than Helm. Here is a set of tools that work well together, Unix fashion. You know, for you to build up your deployment package thingy. That's basically what I got out of this. So it's the seven repos that are listed. Yeah. They're all inside Tanzi now, but would move out to a separate org. Right. And if you look at the sentence here, a common pattern for power users to pipe various CLI tools together. So YTT, which mungus YAML files cable app. You know, they pipe it to each other, essentially like so. YTT is usable separately or you can combine it with other tools. Yeah, I think an easy way to think about this is Helm is a package manager in the traditional sense, right? Yes. It's like apt or homebrew or YAML or any of these. Yes. And it's designed for packages. This is more and so there's a lot in what makes a package manager. So this is a bunch of tools that are small slices of things that you can use standalone or pipe into each other in different ways. Yeah. It's a different way of working with your stuff. Yeah. So they're giving what each of these does and the Kapp controller is one which understands what a package is. And you can, I guess you can do an update to newer versions, rollback and things like that too. So it's kind of like you see the Github's model there, I think. And there is something, there's a controller for secret generation too. So there is an image package that is the Kapp controller for development and packaging. And the thing here is, yeah, they also have something where they can understand, they can migrate home packages to parallel packages as well. I don't think they called it out here. And there is, you know, sufficiently big team working on this, and they want to now come here and see if they can do more stuff in the community. So there is a story about, you know, standalone packages, there is a story about, you know, can I upgrade a package, downgrade a package, that kind of stuff. There is a migration-ish thing from Helm or to, yeah, see, image package can be used with Helm to make Helm charts air-gap friendly. So there is lots of ideas out here that is useful to people who want to ship their applications. Out of interest, how many people are using it now? Is it something that you kind of ship with Tanzu and then encourage people to use it? Yeah, I don't think they mentioned adoption numbers here, but, you know, anecdotally, I know quite a few people use it. People outside of VMware? Outside of VMware, yeah. Okay. Definitely the standalone tools, even if you don't buy into the key app controller stuff, the standalone tools are definitely used outside. So it's a bet to see if they can do better than Helm. And if they do, it's a win-win for everyone. If they don't, you know, there are still options for people who like another way of doing things outside of Helm. Okay, any objections here? Okay, Amy. Yeah. It's open. Thank you much. Okay, 719, Unicraft. I have to give this to you, Justin. What's up with Unicraft? Have you seen this before? I have seen it. This has been around for quite a long time, actually. I haven't looked at it very recently, but it's been around for, I mean, it's been around for, I think so. Well, the thing says it's already a Linux Foundation project and it's been around for four years. Yeah, it says it's part of Zen. Oh, this is going to be complicated. So this is going to be complicated. Oh, okay. I think we pass on this one just for the moment because we're not quite sure how to be able to do shared between the two projects. And I hate that that's the answer, but I think that's the answer. Yeah, hold please. Yeah, hold please. Are we sure it's a Zen project? Just, sorry, I just. Oh yeah, please double check for me. Thank you. That's what it says here, right Zen project. It says that I noticed, but on the page that's the broken four. Not on the home page. I think it might be well be because a lot of these unicunnel projects was projects. See, it's under Zen project flash Unicraft, right. Okay, I think, yeah, we, we have to, we have to defer until we understand if this is a move out of Zen and if so, yeah. Well, I mean, which is potentially something we could do because it's already like, I think we need to put it into that model of what it's doing. Is it moving? Is it trying to be both? Is it what's it doing? Yes. So let's take it out of the, you know, that's my note. They're already a Linux foundation project. We do not yet have a way to be able to share project between the foundations. Right. At this point, they can move. You know, if I mean, if they're, I mean, we could clarify because they could well be asking to move. Because I think CNCF is a better home than Zen. And that's fine, but they need to be a little bit more clear about that. And there's no definition issue to be able to do so as well. So I'll link to the issue as well, Emily. So it says can act as a CNC project, but you know, if they're acting as what they are and that's probably not going to work at this point. Okay, they're moving on since we have a shot on time. Thank you. So, again, Justin. I mean, yeah, I say, Lima's a compound. Lima was thinking about joining as a container D sub project, and then it decided to send box was more appropriate. It's, I mean, it sounds weird. Is it a collaborative project? Is this project that's for creating VMs on max? But the, I mean, the context is it's for building part of a tool is part of the base tooling for creating development environments for running container engines on max, but it still is weird that it's a specific be a tool for running VMs on max, which just it runs on Linux to today, you can create Linux VMs on Linux with it for it, and basically the same way you do on Mac, and again, I haven't tried it but net BSD as well it says, I've done both Linux and Mac with this. Yeah. Again, this is in the same league as, you know, Docker for sure and top. Oh, it started. I started noticing this more when people started, you know, figuring out how their Docker subscriptions would work right like. I, I can talk a little bit about this. If you're using Rancher desktop on Mac or Linux, you're actually using Lima under the hood, it provides a better user. Well, I would argue a better graphical user experience on top of Lima with a bunch of additions and Lima, primarily targeted initially container D and nerdy control work. And it expanded as people wanted to do more like there's Co Lima that I think runs Moby instead of container D. We started doing things in Rancher desktop with it, where we brought in container D or Moby and K3S. And there's other people doing other things on top of it. And ultimately, the reason for wanting to bring it into the CNCF is so that it lives in a vendor neutral home, because it already has multiple vendors contributing to it and as maintainers. And that's their reason is they want to vendor neutral home to own it rather than it being somebody's project up on GitHub with different vendors contributing to it. And they felt it was more appropriate to be sandboxed and a container D project because it's kind of not core container D. Yeah, the submitter for it is one of the container D maintainers. And I think he's the heaviest author to nerdy control. This was a key hero pseudo right. Yeah, names. Yeah, the email slightly different. Yes. Yes, it is. It is good. So they know our ecosystem inside out, you know, having worked with multiple projects so like I have like no hesitation, asking, you know, giving them space here for sandbox. Any objections. Okay, word please. It is open. And this is pretty much all we have time for today, I believe. Okay, let me just do a quick scan here on my bridge. We have four minutes. Oh, yeah. Capsule Warfish is just a couple of days old. Was this a resumption. Which one. OPCR policy. I have questions about this one anyway because it, you know, are they submitting everything because they operate a registry and they have a policy client. Are they just submitting the client or they submitting the client and registry. I wasn't clear on that when I was looking at this. I want to keep the registry. And we have the client and that's something to call the question. So Matt, feel free to ping them, ask these questions and ask them to update it. Okay. Okay, thank you. Okay, thanks a lot everyone. Thank you all. We'll be back three minutes.