 Welcome. This is our Tuesday, December 12th sandbox meeting. Emily, take it from here. All right. Hello again, everyone. We've got a ton of projects in the sandbox upcoming queue that we'll be looking at today, the first four are returning projects, so hopefully we can get through them fairly quickly. Let's go ahead and get started with Kate's GPT. This project applied back in May of this year at the time of application. We felt that the project was a little bit too early phase. There wasn't a lot going on in the ecosystem. We didn't have a good understanding of their impact or integration potential. We asked them to wait a couple of months, do some more socialization, and then come back to us. Since then, they have, there's a couple of talks from Tag Observability Meeting. Kate's GPT is actively involved in the AI working group. That is a co-run under Tag Observability and Tag Runtime. So this one is just a quick check-in with the project to understand whether or not we feel that they are ready for inclusion within CNCS. And I will open it to discussion. They've certainly got a lot of contributors, at least, I mean, not particularly active, but a fair number of them. I mean, lots of single contributors. So I think it's, we have passed the bar for some box of general interest, checking out the contributions. Yeah, I think it's grown quite a bit. There seems to be an interest there. I wasn't able to really determine like, how it will sustain for longevity though, like what kind of model they're going to be running, where are they capturing data? How are they keeping him private? Like all of that will need to be addressed if they were to actually take this project into graduation. But as a sandbox project, I think it's fine for experimentation and also a great project that we should be working with the AI working group. Cause this is going to become more common. So I think they've done a good job since June in getting momentum behind it. Any other thoughts, opinions? Nope. Are we comfortable moving this one to a vote? Yeah. All right. Excellent. Added the vote, moving on. Yeah, I wanted to say they've also added a bunch of community internal documentation, which is a really good side. Excellent. All right. Next up is spider pool. Spider pool applied back in March. We had a needs information request for the project. Asked them to prevent tag network. Um, they also presented at cube con North America. And Lynn son provided a recommendation, um, from the project with a write up. And spider pool went through and provided updates to their documentation, um, to talk through a little bit more around their integrations and address Lynn's additional comments and concerns. Do we feel that we've had enough information from the project to make a decision for sandbox inclusion? And are there any questions? I see a thumbs up from Justin. Thumbs up from Duffy. Okay. To move this one to a vote. Yes. Excellent. Spider pool. Let's move it to a vote. Ray. Easegrass also returning a tag network. Uh, Easegrass is a cloud native traffic or cause orchestration system. They applied back in April. Um, Matt had provided them some comments. We wanted them to present to tag network and, uh, we asked about the IP and trademark implications for donations. Um, they're okay with that. Looks like they had their presentation on Thursday, the 10th. Um, and Lynn provided a comment and they recommended included into the CNCF as a sandbox project. Questions, concerns, comments. Nope. Ready to move this one to a vote. All right. Easegrass. Let's move it to a vote. Next up. Cube stellar. This is also a returning project from March of this year. It's a multi-cluster configuration project for edge. Um, we asked them to present an attack runtime meeting. They did that. Uh, let's see here. One of the other changes is, uh, cube stellar is a hard dependency and KCP. And between the original presentation and now KCP has been contributed to CNCF. Okay. Well, and I asked the project specifically to make sure there wasn't a hard dependency in there. And I believe they have addressed that as well, Josh. So. Okay. Yeah. Either way, they're good. So. Either way, they're good, but I think. It not having that dependency is pretty important for its ability to, to move to the next levels. And I gave that feedback directly to the contributors on there. And I think they've made the appropriate changes. Okay. Any questions, comments, concerns for this project. Ready to move to a vote. Excellent. Cube stellar done. All right. Those are the four returning ones. Those are complete ready to go to a vote. Let's get started on Kraken. Kraken is the chaos and resiliency testing tool for Kubernetes with a focus on evaluating performance under load and scale. Did any TOC members take up this project to do a little bit of research and understanding on it or any tag co-chairs with insights onto this project to help inform a decision? Well, one major issue from the last review was that it wasn't as easy as it seems to be, but it wasn't as easy as it seems to be. So, I think that was one of the things that was really, which repositories they were actually contributing. And they did separate them out into a separate org. Other comments associated with this project. They did also come speak. And present at tag app delivery. And tag at the time gave approval. Pending the, what Josh just mentioned. Yeah. This is the comment. So they had some value proposition roadmap community at the meeting. Yes, it was well received. Okay. Does the tag have a recommendation? Just a question. Didn't we cover this one really last time? It sounds really familiar, but it's still on our queue. So I don't know that we actually made a decision on it. There's a comment from maybe asking about clarification about the really repos that were being contributed. Yeah. It never moved to vote. Because of the, because of the unclearity about what was being contributed. Right. So this is a return basically. There, there was also vendor specific things that they needed to remove. So after they did both of those things. Tag recommendation is that they are approved. Okay. However, I'm tech lead. So if you need. Are we comfortable moving this one to a vote or does the TOC have any outstanding questions? I see thumbs up from Duffy. Others thumbs up from Justin. All right. Kraken moves to a vote. Laws and Mock server. Justin, you're assigned this one. It's not ready. It's very early to early. We should send them back. It's like eight, nine commits. Can Kerr and any others. Josh. Justin, can you provide the comments on the application with next steps for the project so that they can return at a future date? Yeah. Awesome. Thank you. Was a mock server is not moving to a vote. They have some time that needs to pass and some more commitments and community building activities. Justin Cormack is going to be providing that comment back to the project. Next up, QBN. Any TOC member pick this one up, do a little research on it and would like to talk about it. Okay. QBN is an open source Kubernetes life cycle management operator based off of CubeSpray. Reading through the comments associated with this project, they did get feedback from CubeSpray Maintainer about how QBN would be a good ecosystem project for the project. Which kind of raises a question that I have and something that we've talked about in the past, since this is an operator, whether or not it's prudent to have this project go and socialize with a CubeSpray for potential inclusion. As it historically, we don't usually add operators to sandbox projects. Or graduated projects for that matter. Sorry, go ahead. No, I had the same feeling is that typically we haven't included any of them very intentionally for years now. And I don't think this necessarily pushes the precedents to reconsider that decision that we've done in the past. I do think it's super useful. I just don't think it stands alone as a project. Yeah. I went through to the end of the queue, including a lot of stuff we won't review today, looking for governance documents for all the projects. And one of the things I noticed, there's a fair number of operators in the queue. At some point the TOC is going to need to come up with some guidelines around what is the, you must be this high to ride for operators. That is what we've done in the past. I do think it's super useful. I just don't think it stands alone as a project. I went through to the end of the queue, including a lot of stuff we won't review today. Looking for governance documents for all the projects. What, how much, basically, you know, how much project there has to be for an operator to be potentially an independent project versus saying, oh, hey, you should really join the project you're an operator of. I think that's a sound activity that the TOC can engage in. Josh, would you file an issue on the TOC repo to that effect so that we can track that work? Thank you. Is there a TOC member that would like to provide comments back to the QBN project to that effect? Based off of your answer. Ricardo. I can provide a comment. Because they present an intact runtime. Okay. I will assign that to both of you. Second. What, what, what comment about the operators that Scrimsy is another project that is a Kafka operator. I think it's already in some boxes. So, so keep that in mind. All right. Ricardo. I assigned it to you. Ricardo Aravena, if you could add a comment on there as well. QBN is not going to a vote. Josh, regarding the comments for Rook and Scrimsy, if you could also provide those as examples in the issue when you file it so that we can ensure that we're considered of those exceptions or criteria for size. All right. Next up is coordinator. Is there a TOC member that assigned themselves to this to do a little bit of research on, provide any insights and understanding? I was going to swear this is also a great time. It sounds familiar. Yeah. Okay. One of the comments of Ricardo that you had on here was that there was a little bit of doubt on with regarding how it fits into the CNCF and the case ecosystem. Were you able to receive enough information for clarity on that? The comment that you have on the application is that there was a doubt with regarding how they fit into the cloud native ecosystem. Did you receive information to provide clarity for that? Oh, I don't think, I don't think, yeah. It doesn't look like they actually presented it. Any of the tags? Even though that was a request. Okay. So for this project, because it doesn't sound like we have quite enough information, we need to consolidate and pull some stuff together. What I will do is, Ricardo Aravena, I will assign this one to you. If you could provide a comment or an update with a little bit of authorization within the next, let's say give it a week. And if there is sufficient information, we'll move it to a vote. But until then, if there isn't, and we still have outstanding requests for information from the project, we'll return it back to them. Okay. Make sure I comment on here. Okay. So I'm going to go into the comment section for this coordinator project. There's a comment from community six scheduling chair. And he said, you know, it involves, it makes more sense. And to be a standalone sandbox project. Yep. Thanks, Kathy. So for this one, what we're going to wait for feedback from Tigran time based off of that presentation that occurred before we make a decision on next steps for this project. I'm sorry. For Kairos as well, because it looks like the, it looks like there was a presentation, but I'm not seeing any, any result of that presentation in the issue. I only saw the presentation. The conferences I didn't, unless I missed it for the Kairos, I didn't see the presentation directly to the anyone in the scene. Oh yeah, it has the tag runtime meeting recording on the 28th of September, but no output from that. Yep. Sorry. I missed that part. Probably should give somebody from Tigran. Yeah, I think Kairos is pretty mature. For example, they're a framework to create a special purpose operating. They're not like a framework. I do think Josh brings up a good point about licensing around forking a specific Linux distro to make this happen. If that's part of their actual implementation, that should be a consideration that we take into account. They have a comment response here on it, not forking any specific Linux distribution. Okay. Does look like all the maintainers are spectro cloud. Does look like they're doing active work on it. Which for sandbox is not a thing to have. Yep. So would we like to have a comment from tag runtime based off of that meeting, or are we comfortable with the information presented herein to move this to a vote? I'd actually like to comment. Any others. Okay. So we skipped coordinator. We're on Kairos. Yeah. Okay. Just checking. I wanted to make sure that I was following along here as far as like Kairos is likely to go back to waiting. Not sure yet. Yeah. Cool. So let's move them to waiting. We're requesting an update from tag runtime. Okay. Just, you know, I was just looking briefly over how they use Linux in their thing. And they're pulling from external sources. They're not actually including anything in their own code. So I wouldn't necessarily expect there to be a licensing issue, although I would love to send that to an actual attorney. So Kairos is going to be put on hold. Okay. Okay. So we have the same timeframe about a week for that comment back in order for us to determine next steps associated with the project. Okay. Silver surfer. Anybody take a look at this one and we'd like to provide comments, feedback. Can we go back to coordinator first? Please do not lose. Sorry. What specifically are you looking for with coordinator? Where is our next steps? Okay. So, Ricardo is going to provide a summarization on this sandbox application within one week so that the TOC can make an appropriate determination on next steps of either moving it to a vote or requesting more information from the project. Okay. Move to waiting. Silver surfer back to you. Awesome. All right. Comments on silver surfer. Okay. Go ahead and Karina. They did present to tag app delivery. So that's kind of a question. It would be interesting. However. It may be better as part of core Kubernetes. So that's kind of a question. But it is a smaller project and there is precedence with the erasure eraser. I mean. So. The question was, should they present to six CLI? Or. Go ahead and approve because there is a similar project in the community. Okay. Thank you, Karina. Kathy, you're off mute. Yeah. I think it's, yeah, I agree with. That comment. It's a small project. And it's, it's about an upgrade committees, you know, from one version to another version. I think it's good to present to. The API. To see whether it's a better fit on. To that community. It is just about committees. Okay. How does the rest of the TOC feel about those recommendations? Ricardo. I was going to say. I've seen a lot of people writing their own tools for this sort of thing. So. I don't know if it fits in the sense of independent project, but there's clearly a lot of end users developing their own things to do exactly this. Sure. Great pass. Correct. So. I don't know. I know of two other small projects that have not been pushed to the same sea after trying to do similar things. Kathy. That's opinions. I mean, it'll be, I have a hard time believing that six CLI will pick it up given the current. There's like a new adopter of six of CLI and all that work. But at the same time, I do think it probably would be good for them to have that conversation before we vote. Okay. Why would it be a six CLI and not say cluster life cycle? Maybe it is. Yeah. And really other though, having that conversation and understanding whether that's possible before voting on it, I think makes sense. Okay. In the interest of trying to be more efficient with the project's time and the TOC's time, let's say that they do go and have that conversation with cluster life cycle. And they say no, are we expecting the project to come back and reapply and that will accept them? Depends on how much further they've gone with the project at that time. That's a fair dependency. To see members, is it sufficient to send them over to cluster life cycle to have that discussion on whether or not they should be included before returning back to us for a decision? If it's not favorable. I think my one big concern with that would be Ricardo's point that there are multiple similar things. So like what do we do with that? This project plus four others all go to SIG CLI. We maybe agree that there should be something like this in that SIG, but not four different ones. And I imagine that SIG will then either defer back to us or find some other place to help figure out which thing it should be. So to your point about wasting people's time, I'm kind of picturing this turning into a circular conversation if no one wanting to make one of these projects. But I don't know what the right answer then is. So we don't have to select one, but I do think they need to say what additive value or distinction that they're making between the other four within there. So I don't believe like we're picking a king out of them, but I think your point is well taken if they're all providing the same functionality and not very distinguishable from each other. I don't know. We've never had to figure out how we solve what I would say is like a tie, right? Yeah. Yeah. And I think it's different if it's a CNCF project or it's some part of a Kubernetes SIG. Like I think we have whatever we call them competing projects within the CNCF, but I imagine Kubernetes doesn't want competing some projects. So that's what I meant by king making. Like if they're the first one and SIG CLI accepts them, then what does that mean for all the other ones? If they raise their hand the next day and say like, why are those guys special? So let me ask. Go ahead, Duffy. So this is like a really Kubernetes specific though. Like, so I don't. So I would be inclined to say probably not. For inclusion. It's always. Yeah. So he, I think these are all valid points. Let me ask a different question then. Do we believe that this kind of functionality needs to be embedded within Kubernetes as a default feature set. And at that point, if that's the case, is this worthwhile to provide competition between, or if that is not true, is this worthwhile to provide a competition space between projects to fulfill this need for adopters? Like is there value in having multiple projects like this underneath of the CNCF as independent projects? Or is this a fundamental capability that needs to exist within Kubernetes? So Duffy says the second thing. Others. My key is if it's just for Kubernetes, I think it's good to host this on the Kubernetes. I think there's also, there's also another question, which we, I think we, as far as I remember we touched before, for very small scope projects. If it's not related to Kubernetes. I mean, should how we should kind of, I'm doing, I think previously we, we discussed, maybe we should have another category for very small projects. Yeah, we're not there yet though. We have a lot of cleanup to do before we can start exploring that category. All right. In the interest of time and to bring this conversation to closure. Is there a TOC member that is willing to provide a recommendation right up to cluster lifecycle to request that they evaluate this project for potential inclusion as the TOC feels fundamentally this should be a core capability within Kubernetes. Instead of an independent standalone CNCF project. I can do that. Okay. Thank you, Kathy. Go ahead and assign this to you. Maybe just one additional thing is in case Kubernetes doesn't take it. Is there something that they could change that would make it take it to the approach they have to validate thing that is, can that would be interesting. How they validate this API changes. Is there a reason why this would be taken as it is. Is the approach not correct. It could be interesting. Yeah. When you all accepted eraser, one of the reasons for accepting eraser as an independent project was that eraser had plans to expand its capabilities beyond Kubernetes components. In the ability to erase other things within the cloud native ecosystem. So similarly with Silver Surfer, if it had the ability to upgrade things beyond Kubernetes components, it would make it more obviously an independent project. Thank you, Josh for that additional clarification. Okay. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you and Josh. When Kathy provides the comment on Silver Surfer, if you all could provide that additional insight that you shared here on the call for the project so that they have a clear understanding around a little bit more background in the TOC's decision. Awesome. Thank you. All right. Silver Surfer is not moving to a vote. Amy, let's put that one in. It needs info on it. Yep. That sounds good to me. Next one is bank vaults. So I took a look at this project. It's a set of tools covering many aspects of secrets management in the cloud native ecosystem. However, it specifically integrates with HashiCorp vault. So my primary concern with this project, and this is a known issue in the ecosystem is we don't have a comprehensive secrets management solution within open source. Right now HashiCorp vault is kind of the de facto that most organizations have integrated with. And this certainly makes it easier for running on top of Kubernetes. However, accepting this project might provide favoritism to HashiCorp vault as a solution space. So as the project exists right now, I'm not comfortable accepting it into the CNCF unless they integrate with other secrets management solutions that are out there, both commercial and any open source ones that would exist. Justin, you came off mute. Yeah. I mean, especially since this applied HashiCorp vault is no longer open source. Correct. So I mean, I think in general we've refused projects that only integrate with a single closed source project in the past. And so you're saying that would be consistent. I mean, we have technically accepted projects that integrate, for example, with multiple cloud providers that are closed source, but not a single cloud provider in general has been our kind of line. Yeah. So LF edge is actually working on an open source alternative to vault. If they release that, then that could potentially unstick this project, but right now there's no code. Yep. Okay. So I will take the action to provide comments and feedback to the project. But based off of this discussion to you see members, are we comfortable moving this one to a vote? I would say no, I agree with you. Unless, yeah. So is that a yes to go to vote? But we are all of the consensus that since the project only integrates with one closed source solution, they may reapply in the future if they integrate with other solutions. I would concur with that. Okay. That feels like a postponed rather than a vote directly. Okay. Thank you for the clarification, Amy. So we'll move this one to postpone and I have the action to provide the summarization back to the project. Perfect. Okay. I flow core. Any to a C member take a look at this project and have any insights to share on it. Or any tag chairs. They did present to tag up delivery. It is a business process management project. Cloud native architecture. Automates workflows. So I think that's a good idea. I think that's a good idea. I think that's a good idea. I think that's a good idea. I think that's a good idea. I think that's a good recommendation is that it would be a good fit. My only question on that is similar to the project that Justin looked at. It looks pretty early. It has something like 20 ish commits. And I think across the couple of projects that are adjacent to it, it was up to like 40 ish commits. So like what's the bar for. Activity in the project beyond just. Like fit with the ecosystem. For acceptance at this level. I think that's a good idea. I think that's a good idea. But I think it's a good idea to have more community. Work. But there are other projects. That have similar. Commits. They would like to donate so that they can get more contributions. So. It doesn't look very old either. Yeah, I think it's a lot of months. So we'll be like to see them come back in six months. with additional contributions and more community. See some head nods? I mean, for what it's worth in that commit count, it does look like it was an internal project that they open sourced because the first commit is quite large. So we're comfortable moving this one to waiting or time dependent postpone. I think postpone's the right category, right, Amy? Yeah, postpone will be the right one. Come back when you have more. Yep. Okay. Is there a TOC member that's willing to provide a comment on their application to that effect? Sure. Thank you, Duffy. Excellent. Okay. I'm probably going to ruin the pronunciation of this, but I'm assuming it's quesar. Is a low-level container runtime that provides sandbox container solutions? Is there a TOC member that spent some time looking at this project and has any insights to share or any tag chairs or technical leads with insights? Yeah, I look to... Actually, I remember now, I looked at this a while back. I'm just trying to... Hathi, it looks like you might have been in that tag runtime meeting where this project was presented. Yes. We're talking about the quesar project, right? Yes. Yeah. I think it is a useful project. It provides extraction APIs on top of all the different container sandboxer technologies. So it also, underneath, it provides built-in support for the lifecycle management. I think it's a very interesting project and the scope is large. Yeah. I think I would be supportive of going to... It seems reasonably material and interesting. Okay. Do we need a formal recommendation from Tag Runtime associated with this project in order to move it to a vote? Or are we comfortable with the information that's been presented thus far and is captured in the meeting notes for the Tag Runtime meeting where it was presented? I think it's good to promote. It has quite enough information, I think, to justify it. Okay. I see some head nods, agreement. All right. Okay, SAR to a vote. All right. Next up is Cube Burner. Is there a TOC member that took a look at this one and has any insights to share or any tag chair recommendations, comments? Raina, you came off mute. Thanks. They're good for tag observability as well as Tag Runtime, or not Tag Runtime, or Tag App Delivery. They did come present at Tag App Delivery. And they do help fill a gap in that they are a testing framework for workloads at scale. So the recommendation is that they would be a good fit. Okay. Any other thoughts, opinions? I think it provides. Yeah, I think it provides very useful, how to say, useful functionalities, yeah. It provides a tool that you can easily design tests to evaluate performance and scale of components. Of course, it's also a related component platform. I think it's always larger. All right. Are we comfortable moving this one to a vote? Yeah. Yeah, awesome. All right, Amy, cube burner goes to a vote. That means we got seven. We got one last one coming up. Rainforest. All right, rainforest. Any, Justin, you assigned yourself this one. Oh yeah, this was another one that was really, really early, way too early. Okay. So I think we can just tell them to come back later. Yep. It looks like Josh, you had some outstanding questions for the project that they've not had a chance yet to respond to. So let's have them answer those questions and come back and revisit in about a year. Does that make sense for them, Justin? Yeah. Josh, all right. I'll move them to postpone. If you can add that to the comments, that'd be perfect. We have some time. Do we wanna start looking at the other cube, Emily? I think it's worthwhile to do that. Yeah. Okay. Awesome. All right, so let's see here, cube slice. Let's try these two. Justin, Cormac, can you provide those comments back to the project for the one year to revisit with answering those questions for rainforest? Thank you. All right, cube slice. It's a multi-cluster networking application for pod-to-pod communication across clusters. Let's take a look at the project. Okay. Looks like they've got a lot of commits as of three months ago, but not a lot of information in there. Read me. And looks like they've got some bad links. Okay. Am I wrong that this project is just a set of Helm charts? Looks like right now they have a controller and a worker. I would like to send this project over to tag network to get some better insights and clarity on what it is and what it's trying to accomplish. How does the rest of the TOC feel? That's kind of what I was typing up, yeah. Yeah, Josh, to answer your question, it looks like their main project is the Helm chart that installs a number of other sub-projects, like their controller, they have a search generator, things like that. Well, yeah, it provides the pod-to-pod communication across clusters. Now we've been the same cluster. I think it's a very interesting project, but I agree, we can get input from the tag in that one. The link they provide for their organization has all the components and it's free extensive. Okay, I will move them to waiting and have tag network come back in. And Emily, it looks like you've just signed yourself to be able to do exactly that comment. Yep. Cool. Can we take connect? Oh, sorry, I'll let you finish. Let's see here, waiting. Yep. Cool. All right, so that's cube slice. Let's go to connect. Connect is a simple cross-language framework for protobuf RPC. We're building strongly typed APIs, commonly used as protocol buffers and implementations. Got a couple of different ones. It looks like it's just the or with a ton of repos. So we've got everything. Okay. They're looking to use or leverage the cloud native ecosystem for connect to outgrow buff. Tag app delivery, have you seen this project yet or not yet? Not yet. Okay. Do you see members? There's a comment from Lane, I think. But this was really the tag network. Okay. It's not used in any projects at the moment. I mean, you're not used by any projects. I said it's got no connectivity to any other project. I mean, for what it's worth, there's a few of these out there in terms of sort of the API languages. And I expect that we will see more applications in the future from similar projects. That doesn't say whether we should accept it or not. I'm just saying that that if, particularly if we do accept it, we'll expect to see more. I mean, we were somewhat uncertain at one point in the discussion of whether GRPC we should regard it as fitting in our escape at all. I think during the graduation discussion, I mean, although that's widely used in CNCF, whereas this actually isn't widely used or used at all by any project. Also, it doesn't look like they responded really to Lynn's comment. No. Is it worthwhile then? So let me ask a different question. Do we feel like this project is worth experimentation within the CNCF or is it better to have them spend some time, provide closer integrations with CNCF projects for use similar to how GRPC is commonly used within cloud native and then apply it incubation when they reach that level of maturity. Erin, you came off mute. I guess it's if we're just encouraging Sandbox to be Sandbox without a path to incubation, then it makes sense to experiment, but it's really hard for it to stand on its own. It's interesting, but I agree it would have a very, I can't see a clear path to incubation with the current state, but it depends on how, what kind of bar we wanna hold for Sandbox. Josh, you have a hand. Yeah, I think this also raises another policy question for the TOC. There's kind of a minor ecosystem out there with API tools, which obviously have some utility for cloud native, but it's an area that the CNCF has not sort of expanded into yet. And I think the TOC should probably decide whether or not we should, and it may need to get its own working group. I'll turn it over to Karina, but I believe TAG app delivery has brought up an API working group request in the past. Karina. Yes, that's what I was gonna mention. At the last TOC meeting, we did bring that up, and the recommendation was that we look at expanding the TAG scope to clarify APIs within the TAG versus creating a new working group right now. What would be nice is if Kinect came to TAG app delivery and spoke with us about the API work and what we're talking through with APIs. So see some head nods, okay. So next steps for this project's application, we're going to send them to TAG app delivery through, go ahead, Justin. I'm actually curious about why TAG network thinks it's a fit for networking though, because maybe, like if they've got a good argument, I might be supported from that point of view as well. I mean, I'm happy to see the TAG app delivery right here, but I'm more skeptical it's an app delivery piece than I am a networking piece. Who handles GRPC today? Which TAG? I'm gonna go with none. You're probably not on that. But that's it. Yeah, I'm not sure. Yeah, I think it fits more with that TAG network. So how do we want to proceed with this? Because there's the API component, TAG network has already performed a review on it. What will we like to do with this project? We've had a couple of different comments and points, clearly, it's not ready to move to a vote, but I would like to be able to move them somewhere in our queue of work. I think if TAG app delivery is asking for them to come and present, then that's the right thing, no matter what. But I would love a description from TAG network of how and why they feel it fits into the network and to their scope. I mean, which I think that would be useful. Did they say that they supported? Yeah, I guess they did. Yeah, okay, never mind. Okay, this one goes to waiting. What's the next step here? I know we've kind of wandered around. Yeah. So we want them to go talk to TAG app delivery on this project. Karina, can you coordinate reaching out to the project to make sure that you all are getting the presentation that you're looking for from them with regard to the API components? I've tagged Lynn to provide clarification on how it fits within the scope of TAG network. Anything else associated with this project? It sounds like we have some feedback that we're going to need in order for us to make a decision before moving forward, but is there any additional insights that we would like to have from the project or from either of the TAGs so that the next time we see it, we can make a decision? I would personally like to see more integration with Cloud Native projects. Ricardo? I was just going to say, because if you click that merge request that is linked there, update the preferences to connect our GRPC on the avoid proxy, I was just going through it. This is a new envoy and they added a bunch of preferences to this project there. It might be working on that. Okay. It's unclear, but sorry. No, it's good insight. So what we'll do, perhaps have them update their application with more detail on those Cloud Native integrations, particularly with Envoy specifically in any of the other projects. They should, does that sound good? Okay. Let's see, who's the, all right, update the integrations. You have about five minutes. Yes. I think I would like to call it good for the applications that we have today. How do others feel unless you want to try to get through one more? Next one would be Atlantis. It's an app delivery. Yes. So kind of up to you. Like pull it up. All right. Questions, comments? This looks like Terraform pull request automation. Same comment about vault integration. It's like maybe there was a presentation on December 6th. They did come present to tag app delivery. This is where I'm remembering. We had a long discussion about Terraform and whether they should be an open tofu or in CNCF. But they do support open tofu as well as HashiCorp Terraform, right? So we didn't have an official recommendation whether it should be in the CNCF pending. So it'd be great to hear your thoughts on things like that, you see members. So your question was like whether it should be a part of open tofu or whether if it integrates with open tofu whether we would consider it a project within the CNCF? Well, whether it'd be better to ask them to integrate with open tofu however they would like to support not just open tofu but also HashiCorp Terraform. So they would rather be in the CNCF so that it's not just open tofu. Josh? I'm gonna raise another question here which is because we hadn't gotten to this. I wasn't expecting to get to this project and even look at it before. Is this project cloud-native? It integrates with Argo CD. It appeared cloud-native and I wasn't ready to talk about it today, obviously. Yeah, I mean, it obviously can integrate with some cloud-native tools but it also integrates with presumably a number of non-cloud-native DevOps tools. The... There's a number of projects that do both as well. It's just one of the questions I think we should answer about the project. I feel like we're rushing things on this. We should let this one go. Yeah, I agree. Which is great. Our next meeting is going to be January 23rd so we have plenty of time to be able to pick up here where we'd left off. Yeah, so Tag App Delivery, if you all could provide a recommendation associated with this project or additional insights and further comments, I do think it's worthwhile to get better clarity on whether or not the project really is cloud-native and a fit for the ecosystem. There's a few areas of this that I think we just need to spend some more time on. Sounds good. Okay. One comment about this project is that I've used this project before. It's just like Terraform Enterprise Cloud but the open source version of that. So I think it's one of the ones that are concerned that Terraform is just like the only integration. Okay, yep. Okay. All right. So we got through a lot of projects today. We've got our next Sandbox application meeting coming up in January. Right, Amy? I know you just said that. Cool, January 23rd. All right, TOC members and Tag Chairs for the next Sandbox application review meeting, please grab a Sandbox application and spend some time doing research on the project, asking questions. That way when we have another one of these, we can speedily go through all of the projects again. Our backlog is getting quite long because we are popular. So please, please sign yourself, provide comments, insights, updates so that we can have a fruitful conversation in the new year. All right, if I don't see you all before then, please enjoy your holiday break and we'll see you later. Enjoy the rest of your day. Have a great holiday.