 All right, welcome to your March 8th sandbox meeting. Dimms, I'll pass to you. Thank you. So today we start the conversation around Ego and Marble Run. Those two are a pair of projects. Ego is about the Conferential Apps, and Marble Run is a control plane for Conferential Computing, but we have three projects in the same space. The third one is the Confidential Containers, which we talked about last time. And Justin, do you want to say something about what information we got from them? Yeah, so I had an informal discussion with Confidential Computing Consortium. I think that they would be interested in having more formal, full discussion about this, but the feeling was the Confidential Containers was appropriate as potentially as a CNCF project. The other two much less clear whether they really fit into our space. I think, but the other issue they raised was that right now it's difficult for these projects into production because you can't generally run them on your own hardware, and there's limited hardware available in the cloud in various places in restricted ways. And so from our kind of project, maturity point of view is not clear that at the moment they could move to incubation in any kind of foreseeable future because people would not be able to adopt them. So they might kind of be, they might become stuck in the sandbox for some unforeseeable period of time. Erin, you had some thoughts? No, okay. Anybody else had an opinion on Ego and Marble Run? I do have some thoughts. I could not get out how to unmute because Zoom changed the thing for me. Yes, I think in past discussions that we had had previously that we didn't really have a path to the next level to incubation and graduation for these projects. So at this time, I think it's a no until we have a better feeling for how we would support and how that would enhance the ecosystem. Okay, so do we wanna take a vote on this, Amy? It sounds like you've reached consensus. So yes, go ahead and votes for both three. Actually, that's a question. No, let's do for Ego and Marble Run, please. Okay. All right. Great, vote is open. So for the new members, it's usual plus one, zero, minus one. All right, not included, then we can move on. Thank you. Is the next one confidential computing? Yes, let's wrap that up before we go any further. So based on the talk Justin, you had with confidential container, confidential computing containers, I forget which one is which. So let's open the vote for that. Vote is open, go ahead. Thank you. And the vote passes. Thank you much. Thank you. We've got some really good questions. I think we should be clear to them that incubation may be potentially difficult for them to reach and just let them know that. Plus one to adding the caveat. All right. I think we can move on to our re-applications. Can you call them out Amy, please? I have Fabbage, I have Lagoon and I have Conveyor. And let me go find Fabbage. I know how to find Conveyor because it's the last one. So let's take that one first then. Yeah. Okay. So this is a resubmission. We got some feedback from our delivery folks. Now, what did they change? That's a question. Yeah. If I remember right, we were saying that it feels like there's too many projects, sub-projects that are sometimes not related to each other. That was one concern that we had. The other concern we had was, what was it? Yeah. OpenShift focused, I guess was the other one that we were talking about. Do we know where exactly the feedback was? Was it in an email? I think there was also a recap during the public meeting from the SIGGAP delivery. First the email from us and then yeah, then the recap. Do you remember what it was? No. Okay. Fine. I think basically they said plus one and they didn't say no. So for the new folks, do you have any questions about this one? Because the rest of us have gone through it once. You said something about OpenShift in here and it being tied to OpenShift. Yes. Can you expand on that a little bit? Yes. So if you dig into the individual projects, there are four big projects in there. If you look at the install or how to run kind of thing, all of the, most of them had a requirement of OpenShift being there and being able to run on OpenShift rather than brand vanilla Kubernetes. There is still a lot of OpenShift within the repository from the majority of the projects. Correct. Yes. And there isn't that much for Kubernetes by comparison. It's not like an even 50-50. Right. This was a project that was started around lift and shift of existing workloads to OpenShift. That's why, based on the history, that was the, that's why it is the way it is. Richie, any questions? What is the immediate value or what is the perceived value that we're gonna get out of this is my question. Yeah. So the perceived value here is there's lots of workloads running still which are not in cloud. This is a project that will help move some of those workloads into the cloud and by cloud I mean here. Kubernetes-based, this time. Well, I mean, it's not going to move them into Kubernetes. It'll move them into OpenShift and it obviously requires some specific things in OpenShift that aren't general things that you can install into your Kubernetes cluster. Yeah, that is the problem. Yeah, that, I mean, it raises the question for distros that have their own sets of APIs that are not part of the compliant Kubernetes and they specifically target just that distro. Do we want projects like that in the CNCF that are just known to really target a particular distros specific APIs? I think, yeah, as long as the intention, I'll go ahead Dems. Yeah, I don't remember having allowed anything like this before, but any sandbox, right? One analogy I could kind of think of is if you remember cloud custodian, I think it initially only targeted like AWS, right? And they have evolved over time to support other clouds and quote unquote platforms. I could see something like this where maybe they started with OpenShift due to business needs or whatever. And as long as their intention is to support different distros, different platforms, then I think it's fine. It doesn't like raise any red flags that in our charter, basically one of the values is all about supporting different platforms and environments. And as long as they stick to that, I think that's okay. It's an early stage project. Okay, if there are no further questions, we can take a vote. I expect this to be mixed and let's see if there is support to get them in. Just a follow up to what just Chris just said. I, looking at their roadmap, they talk about supporting OpenStack and they talk about a journey true towards Kubernetes, but not like into full plain Kubernetes. So maybe this would be something to either ask them or to make a condition of any future incubation status to basically require a statement, interval method. Yes, they're actually going to support vanilla Kubernetes. Because OpenStack smells like not bad, but weird if it's coming before native Kubernetes. I didn't get that sense. Which repo are you looking at for the OpenStack, Richie? The, their roadmap presentation, I link it pages seven and eight. Yeah, that is for one of the projects that they have, four projects that they have. It is, but it's still smells weird. Yeah, for sure. Thanks for pointing that out. So based on this information, we can take a vote. Well, am I missing something? Cause I don't see them saying general Kubernetes support is in their plan right now. Did I miss that? No, that's the point. You see OpenStack, but you don't see generic vanilla Kubernetes and that just smells weird. So under Forklift, the documentation talks about migration to Kubevert on their site, but that is it. And it doesn't match up with the roadmap. So there is a clear disconnect in several of these projects. So one other thing, why we are looking at why we see OpenStack there is probably because they have a workload that is running on OpenStack that can be moved using Kube, moved into a Kubevert environment. You see what I'm saying? They're not trying to, the support would be like the from component would be from OpenStack into Kubernetes. So because it's Forklift, right? That's what makes sense to me. From OpenStack to OpenStack, yeah. Yeah, it's the project for the virtual machines inside the Kubeer, right? So it makes sense that they mention it from the OpenStack to Kubevert, not like to Kubernetes, but it implied. Right, if we see something else in like Crane or the other three ones, then it will be of concern to me. Sure. Okay, once, twice. Okay. Just to be clear, are we voting on asking or are we voting on? We're voting on acceptance with the asking for condition of incubation. Okay. So if we get a positive reply, then I'm fine. No, no, no, hang on. This is inclusion into Sandbox and then if they're going to move to incubation, then we have to be able to have that requirement for supporting vanilla Kubernetes. Right. Thank you. Is there a strong reason not to ask them before? Because it's a re-application and we're going to have to, go ahead, Demsha. It's the carrot and stick, right? Like, so we kind of like get them into our form. Sure, there is a plenty of things that they need to take care of. We want them to take care of those kinds of things and get new people on board and then start working on things like this, Richie. Okay, okay. Sorry, I'm still getting... Oh, no, no, no, please. Ask interrupt any time. Okay, so... Give me a bit in here. That's not helpful. This is good. So they didn't take it. I'm seeing four now in favor. I have two against and two abstain. I believe I'm missing Dave. Dave, are you there? Yeah, I'm on my phones. I was typing into chat. I want to copy and paste the thing that Matt said. I want to actually see ready support from the roadmap, but it's taking me too long to type it into my phone. Okay, I will count that verbal vote as a negative and there are three of those. So this does not pass. We'll go back to them with what we were looking for. All right? So we give them the feedback that we want strong support for generic Kubernetes and what else was there? I think we'll start with that and see what else happens. Right, and then come back to us when they have it. I don't know whether they should come back to us when they update their roadmap or when they actually do it. The updated roadmap is good enough for Sandbox seems completely reasonable. It's like we didn't ask Cloud Custody and to go support another cloud before they accepted. Okay, so for all the people who did minus one and zero, will that be enough for you to think about next time? Okay, yes. Okay, thank you. Okay, so that's it Amy. Line 11 will give you Fabbage. Fabbage, yeah, okay. So Fabbage was another thing that we talked about last time. So somebody for the new folks is, the question here about, so Fabbage says that it's a Kubernetes CNI, but the traditional definition of a CNI, it doesn't conform to that. It says that you should have another CNI by default and this will be an additional CNI for just edge computing scenarios. So we were confused what it actually does or what it actually wants to do. So we took it back to them. I don't know if you got feedback. Was there a comment or something? The application, I don't see them adding any updates here. So for clarification, the previous application is line number 39 on the previous application is not included if you wanted to be able to take a look at what was previously said. Yeah, so they added a lot more information this time than what they had last time. That's what I can see. They have fleshed out more of their application. So given this new information, it says it works as a Kubernetes CNI. So it serves the project, I guess, which are all under CNCF. Okay, that sounds decent. Closely working with the different communities. Okay, similar projects. Kubeh, KubeMesh, HVPN. Okay, so the TLDR seems to be that they're already working hard with these other CNCF projects. And how are they doing in terms of, does anybody else have any observations? Do we have any idea why their contributions have all dropped off? No, let's check their date here. See, 1228. So they applied and then they stopped, I guess. Some of that pair is Chinese New Year. Right, so they have a decent set of people, smallish, working on things and they are working with existing communities. So that's basically the TLDR here. And they are working on a new use case where we don't have too many things at the networking side of things. I mean, yeah, we have a lot of projects on the Kubernetes is at the edge space, which I think is good because it's not a well understood space. There's a lot of experimentation to do and there's a lot of interest in it. So it seems kind of reasonable to me. I mean, at some point, these projects are gonna have to turn into, they're gonna have to get some agreement on what has been successful and what are the right ways to do this thing. But they're still early at this point, I think. Yeah. I agree. And I think the CNI is pretty critical to the cohesiveness of running it and from edge into a more centralized infrastructure and how that would work and whether or not it scales down to that size effectively and still is feature rich enough. So I think we'll probably end up seeing more projects in the space coming here. Okay. Ready for work then? Yeah, let's do it. The boat is open and I know we're nearly at time. Yeah. Okay. Thanks a lot everyone. Thank you very much.