 All right, we are now recording. Welcome to the sandbox review meeting. So please hand off to you. Awesome. Thank you. Yeah, so we have a lot of applications, I think. How many do we have I'm just quickly counting it's 24. And I think maybe there's three that I had heard of before. Reading this form ish. Which just slightly made me wonder whether some of these projects are. Yeah, very new, very. And I don't know whether we should. Don't know whether this is a signal that we need to somehow slightly clarify. I mean, I know our barriers to entry here is low. Oh, Chris has mentioned the VS code thing. Yes, I think that's that was one of the ones I've heard of. But yeah, without changing it such that we, you know, we still have that experimentation we still have the let's be really open to neutral collaboration but I wonder if we should be trying to spot what it is that maybe. I don't know, I just have a not great feeling about this list as a overall list. Anybody else want to comment on that. Yeah, I share the same concerns because I read through them. And I haven't heard many of them either. And some of them actually are very much in the area of what I'm working on to so very surprising because then I ended up asking colleagues, and they haven't heard about those either so. So, you know, they're very basically it is not basically really, really new. And it's hard to make I mean I didn't have time to actually install it and run it, because I just don't know how I can possibly make a judgment of the quality of the of the of these projects so that's one of the struggle I had. It's, you know, I was looking at how professional they are in terms of the documentation the write up so I can kind of make those types of judgments but without a without a longer track record of seeing the community adoption and community responses. And it's, you know, I think, I will probably personally need more time to play with those projects to to at least try to form an opinion it's it's it this is actually quite this one is amazingly quite challenging for me. I mean, I should have started earlier to to review the projects but I was doing it yesterday. Hello, sorry I'm late that meeting ran way over just made it in time though. We haven't actually started discussing individual projects but we were kind of raising our sort of general worry about whether the. Well it's interesting that we've got such a long list of projects that most of us have not heard of and whether or not that says something about the. You know, while we want to encourage experimentation but I feel like there's some kind of. We've lived this forever right like the balance of, is it viable, or is it just experimentation and they want publicity I don't know, is that what we're getting at like. Exactly or people thinking that like every project is best off in the CNCF is there no other kind of route for people to run open source projects that you know. And for me it's just the difficulty to judge because. You know, like I said I didn't unfortunately I didn't have time to actually install and pay with those projects myself so so that would probably be what's honestly what's required if a project has only been, if I couldn't find much evidence of. Community adoption or comments or made or or slack channel activity so it's that that's what makes it hard. Or like if I asked other other people I know and they haven't who's supposed to work in that area they haven't heard of it either so it just made it very hard for me to judge that that's all the subjective judgment is. But yeah we can go through them and. Yeah, I also wonder if, if tags can help us somehow here because I know some of the projects they come to talk first, and they give a presentation, and the tag cheers and not in these they form some opinions about the projects and that's probably something that we can benefit from. Yeah, we also don't have to go in order, you don't have to go like first and first out here, you know there's different projects here that have different maturity levels here so the TOC could choose to focus on particular ones first or an area. It's really all up to just stuffing share for a second sorry. Yeah, no worries. I'll be applied before and. Only issue was with the name and they've changed it. Sorry that was the open ELB one right. That's right. Yeah. Sorry I just wanted to be able to open other windows as well so can you still see the sandbox thing if I do that's good. Yeah, so. Yeah, so we looked at when it was called Porter before we looked at it was it just the naming that we were concerned about last time. That was a main hold up I think. Yeah. I think this was, we talk about the differences that's right because we had metal be at the same time last time didn't we, and they've written a post about the advantages compared to metal be. So this is from a company called cubes fear, and they are doing, they have one more, which is the last one open function. So they have one more submission I don't know what others they already have in CNCF. I mean I guess, in terms of the characteristics we normally look for it. It's got a reasonable number of stars and things like that it doesn't look anybody got any comments or should we take this one to a vote. All right, so votes for open ELB. So next one. Can I make. I'm not sure I can make that fit all on the screen so open cluster management. Maybe look at your own copies. This was a red hat project I think. Yes. Yeah. And they seem to have, I mean, you know, taken by from their comments they seem to have lots of collaboration going on already so. Any points anyone wants to raise that open cluster management any concerns. As such, I, I liked what they were doing with the different caps in cubanitas. They are piggybacking on some of the submissions from like Google to stitch things together into us. You know, state the stitch multiple clusters together. So that was a good sign for me. Yeah. I think having been part of that in my previous life, you know, I think there really was an effort to not have it be open shift focused and really go away of the community. There were some architectural decisions made early on to like pivot away from more IBM open shift way of doing things and how the community was doing it. So I think they've fully embraced that that's where it should live and grow. It's needed. I mean, this is from a customer use case end user like having this is pretty key to a lot of different large and small companies. So I like the idea of it growing. I would have liked them to call call out what you just said and that this is not open shift specific. I don't see that. It's really since it didn't even start in open shift, like, it's been out of the cluster API working group or whatever they were called. No, I mean, there are definitely people that worked on. What was it? SIG multi cluster and then cluster API. I think it's a lot of different people trying to accomplish the same thing. So this originated on the IBM side of things and then went over to red hat from what I was told. Correct. So, IBM had it. When IBM bought red hat, that hat took it over and said well we're not going to do it unless it's open source. So it took a fairly long amount, a lot of effort to then open source it and then to look back and make sure that the technologies that were chosen as part of the architecture really fit within the landscape. Like, there was a pivot to, you know, get ops instead of she said things like that that changed underneath to be able to support both the models to make it more open. Is this related to, like, I remember there was this IBM thing called advanced cluster management that was announced a few years ago. Yeah. Yeah. Oh, I see. So it's sort of the open source descendant of that. So it's, it's got a longer history that then it was one thing I was trying to find out there was a, how new a project with this because it seems pretty substantial but but it's also very new. I guess that kind of explains it. So it's new in the sense of recently open sourced, like in the last year per se but the project actually has been around for quite a while so it's, it is fairly mature in the sense that it's been worked on, you know longer than this repo would indicate, just because it went from being closed to open. Right, so that may also suggest that. I mean, things like the number of stars are pretty small at the moment but that may be, you know, because it's so new in open source form. I mean it is interesting that I mean, assuming that the, the main repo is open cluster management IO slash. It's got 78 stars. I mean, maybe that's enough for a sandbox but but I mean the commentary of it and the history of it makes it look much more mature than that I would say. API has got 169 stars. That's the I think that is the long guess, maybe the oldest one I was trying to work out which is the original. That goes back to March 2020. Yeah. Should we do votes. Okay, I'll put votes. All right, next up is qubitus installer. Similar projects of him with hands. Not really, but sure. It's quite a statement. It's interesting that it's on get lab do we have any. I can't if we have any particular sort of rules or reasons about that. No. Get lab is fine. It's only an answer playbook. I didn't really get what it does exactly. Yeah, an opinionated collection of answerable playbooks. And it's based on coup spray. So I guess it's a book written on top of coup spray. Less familiar with get lab than I am. Get hub. I'm seeing like one star. Am I looking in the right place. I was also curious, like I'm looking at the releases and it's empty again. Not a, don't have experience working with the get labs. I'm not sure the right one under deployments releases. There is nothing. And I think there's only one developer from the commits. Yeah, I mean, it's, it's, you know, if you look at the architecture, it's very specific. It's okay. I think it's totally okay to. Use get lab to post a project or use get lab as a good repo, but this is like literally has good lab baked into the architecture itself. It's, it's very specific. It's almost, it is a very opinionated deployment of coup spray. I'm also pausing on the why do you want to contribute your project. Answer, which is more visibility and more contributions. Yeah, we asked them to come back after six months. And is this a six month checkpoint. You mean did they come, come to us before. Yeah. I don't remember this, but. I don't know. This project is more than six months out. Yeah. Yeah, there are three, three additional members other than the primary guy and all have been added only four months before. So probably most probably not. I think I would want to see April, April 26th initial commit. There's only one actual contributor. Yep. You know, I want to see like some, some evidence that it's actually turning into a community project. This looks like one person offering. And I mean, even if it was a community project, do is it in itself. It's a community project scale project given that it's based on CubeSpray and CubeSpray is not. I think CubeSpray is hard. To be a contribution to CubeSpray. Well, yeah. Yeah, I just, I just don't think it has substantial generic utility. You know, it's so specific. One team or one person is using CubeSpray and GitLab to configure Kubernetes clusters. That's what it seems to me. So I had a proposal at the beginning. Should we go to, well, let's deal with this first. Do you want to tell them to come back? I don't know. I don't think, I just, I mean, this one is not, I don't think it kind of qualifies as a, you know, just, I think it just lacks substance. I think, yeah, let's, let's drop the pleaser reply. I think if it's, if they did somehow suddenly get a huge amount of community adoption and that suggested that there was a kind of consensus that this was the right way to install Kubernetes then maybe, but even still it just seems too, too opinionated, too specific. And I think if we tell them to come back in six months, we might be saying actually no, we don't think it fits anyway. I agree. I think it's okay to say no. Yeah. I think, I think let's drop the pleaser reply. I mean, you know, there's, there's got to be a kind of implied if the situation changes, you know, maybe we'll regret this decision of saying no and we'd like to kind of ask you to come back, but I, I don't think we will. I think it's too opinionated and too specific. Do we want to vote on this or we probably should. Otherwise, I won't know. Oh, it's insisted on re turning that into key bits like measurement. Okay, we are down to 20 minutes left. So I had a thing at the beginning. I posted like five projects. Could we go to them instead of going through each one by one? I think we'll see many more of these. We're going to deal with the same way we dealt with. Oh, I see what you're saying. Yeah. So VS code Kubernetes tools. Let's do that one next. I think that does make sense. Can you start the recording second? All right, we're back. Go ahead, Dimash. Yeah. So what drew me to this one was, since the plugin essentially is editing the stuff that is, you know, code schema stuff from the Helm and Kubernetes projects. If it's closer to the ecosystem, then the plugin gets will get updated sooner than later. And if it is self-contained that people can build and use with the local version of VS code, then, you know, it might be easier to update the plugin as well. So that's what drew me to this specific one. I don't buy it for a few reasons and I love VS code. I use VS code all the time. I think it's brilliant, but I don't buy that we should be supporting an extension to a platform. And thereby, you know, we're essentially putting an endorsement behind a particular IDE that is not part of the, you know, it's owned by a particular vendor. And I just, I feel like that's setting a really bad precedent. And I don't buy the argument that says becoming part of the CNCF would buy vendor neutrality for the VS code extension because I think the VS code extension has to work with, you know, for it to be successful. It has to work with Kubernetes and Helm and whatever other projects that ecosystem drives it towards. Am I completely off base with that? If we had precedent before, then yes, one more thing we wouldn't have minded just like, you know, we have, you know, SDKs and Kubernetes, then adding one more is not like a big deal, but we are starting new. Sorry, Chris. Yeah, I mean, the way I see it is like they're coming in as sandbox, you know, I think this is an opportunity for them to open up that, you know, project, you know, more, you know, VS code by far is the most dominant ID out there used by developers, right? So having something within CNCF that's supported by more than just one vendor long-term, I think is a good thing. But I think the onus is on Microsoft to prove that they could do that. Like we wouldn't move them further along incubation graduations. Kind of how I, I don't think we can be drawing lines around like, oh, you know, sandbox has different rules for what we consider to be cloud native or what we consider to be neutral. I really, I just feel like it sends a huge message that CNCF says you should use VS code. And as I say, I do use VS code. I love VS code, but I'm not sure that that's a message we should in, you know, it's not a neutral message at all. I mean, one way to spend this, would you be willing to take like extensions to like Vim or Emacs or IntelliJ down the line that we're supporting Kubernetes development in those tools? I'm not sure what the benefit is. Like, does it actually, this is another argument for it. This is, yeah, maybe part of the ecosystem for cloud native, but it doesn't, it's not actually cloud native code. Well, whether it is cloud native or not is kind of irrelevant. It's, it's an editor and we don't want to become a home for all the editors. Correct. I think, I think the argument is, is, yeah, I mean, I can relate to the substance. Just does it have enough, the project itself, does it have enough substance to stand alone, to be healthy? You know, I mean, obviously I could, I could imagine, say, some, some major feature like Kubernetes itself on Windows. And that is, that is very important. That's very substantial. But given the plugging on the editor, I think that's what the argument is. It's, it's, it's, it qualifies a standalone project. Well, it doesn't qualify in the sense that you cannot use it without VS code. So what's the nice way to say no? Do we say that we, we, we don't keep a CNCF doesn't yet has a policy around IDE and IDE plugins. So instead of saying no specifically to them, we, we can like, I'm asking because there is number six, no local host. It's in the same boat. It's an IDE for both VS code and JetBrains. So, you know, we could say that we don't encourage IDE and IDE plugins right now at this moment. I think the plugins though would have to work across platforms to be neutral in us. It's the same discussion we could have just had with the Red Hat discussion. If that only worked on OpenShift, we probably wouldn't have blessed it as part of a sandbox, you know, but it's, it's, you know, uses lots of different products, projects, and it's not specific to anything. And I think this is where the argument stems from. So those plugins can be widely used amongst many different IDEs than I think it does fit it. I don't think we want to have a blanket statement that we feel like tooling is irrelevant. Okay. So we take a vote. Chris is making a comment about other vendors. Other vendors maybe depend on this code. Do you want to serve? Yeah. They will remain nameless, but there's other people that, you know, depend on this and embed it in products that would prefer this to be a little bit more vendor neutral and not fully controlled by one vendor. But how does that, I mean, VS code is controlled by one. The IDE, but the plugin, right? Like the IDE is basically it's, it's out there. It's like de facto, almost standard. Right. If you're going to be building tools, you're generally going to have to write extensions and VS code to, to support them as, you know, depending what type of business you're in. So, you know, if you're a red hat or someone and you're embedding, you know, supporting Kubernetes, you need, you need to generally have some support for VS code extensions, right? I believe the OpenShift team does this currently in a round about way. I get what you're getting at. Yep. Hmm. Oh. It's a scoping question at the end of the day, I think overall, if we want tooling like this in the organization, but anything that we could get out of potentially like the largest tooling, IDE tool for Kubernetes, most widely used to a vendor neutral multi-company governance thing, I think is a good thing. I look at it from that perspective. I just, I just feel like it sends such a non-neutral message. I mean, I would be interested to hear more about this other vendors that, you know, I mean, if they have a dependency on VS code, then, you know, either, there's still a, I mean, VS code has that sort of marketplace model, right? So they can still ship other plugins and so on, right? Yeah. I mean, it's an open marketplace. There's actually a whole thing called like there's open, or no, there's the VSX exchange. There's like an open marketplace outside of Microsoft control too. So there's many ways to kind of distribute these, you know, plugins. But from a neutrality point of view, I view it as like, if IntelliJ or someone else came up, you know, or the Lens project, that's kind of another one that they're doing some interesting things, like if they came to CNCF, I don't think the answer would be no if you accepted, or if all y'all accepted this project. You're basically saying like we're open to any type of ID that makes Kubernetes more consumable for end users. I think there's two separate things, neither of which we have precedent on, well, one of which we kind of, we kind of have negative precedent on. So one is do we accept projects that like have a huge dependency on something non-neutral. And I think we don't. And the second sort of orthogonal thing is do we accept IDEs? I feel like that's... We picked some projects which are specific to Intel, that we need support. Runtime, if I remember right. Like an SGX thing? Yeah. Yeah. And that's Intel only. That's interesting. Yeah. I mean, I suppose back in the day, everything was Intel only support regardless. Yeah. But now we have ARM, so it's different. And RISC-5. So I don't think accepting Intel means that we won't accept ARM or RISC-5, right? Just like accepting something for VS Code means we won't accept IntelliJ or whatever the other IDEs. And I agree with you, James, that the no-core hosting falls into the same kind of bucket. What tag does this even fall under, or does it not? App delivery would be probably the closest. Yeah. Some mythical tag developer experience that we don't have. Correct. That would be another one. Yeah. This is more app development. Yeah. Yeah, it's... Yeah. Maybe... I mean, maybe that's the evolution though, right? Of how things are coming about. You know, we're getting away from the guts and more up into the app layer. I don't know. Maybe it's a consideration we should start looking at. It looks like we're getting more things around this. Maybe we need a working group that's looking at this more closely. When tech gets mature, it eventually ends up in an ID. In the end, it'll end up with a chat function, right? You can point and click four things and you generate the YAML for you. Absolutely. Once you get ID wizards, you know you've made it. When are they introducing Kubernetes stories? Oh, goodness. Mythical tags are out of scope for this call. But can they have unicorns on them, Amy? There's only so much we can do. Time check. We have five minutes. Yeah. Shall we... Are we ready to hold a vote on VS Code? Yeah. So Chris, that lens project I think is slightly different for two reasons. One, if they donated the entirety of lens, they would be donating the entirety of lens. And the second is it is Kubernetes focused. It's not an all-purpose IDE. But I agree it does take us into an interesting space. I mean, my perspective is given how predominant VC Code is. And as long as there's enough substance in this project, I think it qualifies as long as... And this project itself is 100% MIT open source and Kubernetes focused. So I've been... Anyway, I'm certainly inclined to support it. Yeah, let's vote. At least we'd be able to give you one more project. All right. So, yes. Oh, wow. I think this is setting a dangerous, dangerous precedent. I want people to make it easy for people. Yeah. That's Sandbox. Yeah, but I mean, Chris, you say that it's Sandbox, but Sandbox is supposed to be experiments that either succeed or fail. I don't have a part that says, we've decided this isn't appropriate for CNCF. Yeah. No, that's a scoping thing. I think the experiment for me is, can the project move to a multi-governed thing where multiple vendors that build upon and depend on it and products could participate? That's how I... So, one more thing that's moved into its own thing altogether. I guess I agree with that, Pat, but I... I don't know. I mean, the local host one supports multiple ideas, which I find more neutral. Like, I don't know. Would Microsoft be supportive of this plugin supporting IntelliJ? I think there's pro... Yeah, I don't know if the question makes sense. Like, maybe they have like underpinning technology that could be reused by IntelliJ. Right. Like, there's probably extensions that are built specifically for BS code, but maybe there's some underpinning core libraries that other IDs could use, if that makes sense. Well, I don't know. That's the one thing. The local host one supports both, but I don't know if the code's just duplicated. I mean, it's just two projects, but... Yeah. Or whether there's actually some overlap, because that would make it more neutral if it was ways to interact with Kubernetes in your IDE. Yeah. Yeah. I mean, I think Microsoft's track record has improved, so I'm like a little bit lenient here, but, you know, it's up to all y'all. I mean, Microsoft Against is not in any way intended to be anti-Microsoft. It's just pro-neutralising. It's widely used. It's extremely widely used. It has over a million installs type. I mean, okay, I'm going to vote for it then. I'm going to see it as an experiment. If it doesn't work out, it's sandbox. Lists can vote to extricate it. I'm going to say that passes because a zero was counting as an abstention. That's neither for or against. Oh, now it'll be all on Microsoft. Erin, come back. Thanks. So... Which one else is going to call JetBrains and now it's going to submit a Kubernetes plugin for IntelliJ? Yeah. So should we do votes for NaCl host as well? I'm going to be nothing if not consistent. Yeah. We're at time almost too. Yeah. Maybe we can squeeze this in or not. Elena, cast your vote before you have to leave. Oh, no. I guess you can. I think she's already draft. I'm still here. What are we voting for? We're voting on NaCl host. I think I need more time on the no local host thing. Can't do it today. Okay. Yeah. All right. I guess that is where we are then. All right. How do we want to handle like the... If I have seven of you, a quorum is eight. I believe VS code does not actually pass because Erin is only one. So we've written this up before. Let me check. That's why I need help. Yeah. Because it depends on the number of attendees. I think I pinned it to the channel. Right. We need a minimum of eight TOC members to make a decision. Sandbox approvals a simple majority. So we need over 50% of those present to plus one. And therefore VS code does pass. Yes. All right. Included. We didn't get enough votes to be quora. We had time. So. All right. Yeah. Thank you all very, very much. Take care.