 Hey, how's it going Alexis? Hey Chris, good to see you. Yeah, we're gonna get started in a couple minutes. Is Cantrell here? Yep, I'm here. Cool. Morning, morning. Alrighty, is Brian Grant or Camille on the line? Yes. Good to hear from you, Brian. Ken Owens or Solomon? I know Ken is supposed to show up. Okay, it looks like Camille just joined, so we're good. We're good to go. Alright, Alexis, you want to kick things off? It's about five past. Thanks very much, Chris. I understand the process of getting the slides up. Great, if you could just talk us through the process for the TOC reelection. Sure, no problem. So on slide six, we've mentioned this in the past that two seats are freeing up on the TOC. These are TOC selected seats, so essentially the TOC themselves votes and nominates these seats. So if you're interested in running for this, I would highly advise you talk to your fellow TOC members. Nominations are opening up today. The TOC has been nominating some folks. I plan to close in nominations March 6, and then we'll do the voting for about a week. We'll close voting on March 14 and announce the results on the 15th. Any questions? These are Brian and Solomon's seat, by the way, Brian Grant and Solomon's. Presumably Brian and Solomon need to be renominated. Brian Grant has already expressed interest in being renominated, so I put him on the list. Solomon has not yet said anything. So please, if you're looking to be nominated, then members of the voting TOC will probably oblige. I'd say there's a relatively low probability of your request for nomination getting rejected. It may happen, but it is in my view unlikely. But you do need to be nominated, so if you're interested in this, don't be ashamed. Throw your hat in the ring now and tell Chris or someone else. Okay, good. So I think the next topic is the proposed sandbox model, correct Chris? Yeah, slide seven. Yeah, I'm now in the deck. Great. So, you know, here's what we came up with after the last TOC meeting, where thanks everybody for all of your feedback on the sandbox concept. That was super helpful. And we've now got a document which has largely been written by Chris. Thanks, Chris. With some input from the TOC and a few other people, which we would like to move to a vote as soon as we can, maybe not today. Has everybody read that proposal? If you haven't, do open it now, have a quick read. It's not a long document. I don't think it's feasible for us to vote on this today, but I think we can discuss the absolutely most important points. One of which is that we have an explicit declaration that we're not going to do marketing, and there is an attempt to clarify what that means in practice, because in reality, we are going to do, we hope to publicize projects in the sandbox so that people know they exist and might want to contribute to them. But we want our focus to be around building community rather than, you know, going around saying, this is production ready, everybody should start using it right now, which is what you would consider normal product marketing. So that's one important point. And there's quite a lot of language in the document about playing down expectations here. I'm really looking for people to vociferously object to any of the language at this point. Secondly, we've tried to come up with a model where the bar to getting into the sandbox is lower than inception. Because one of the issues we run into that caused what somebody amusingly called storage gate is that there was a perception of blessing or election to some elite by being made an inception project. While we do think that, you know, getting recognition is important. Nonetheless, we wanted to kind of take out the idea that we're processed similarities between the sandbox and incubation. So for example, we don't want to have a vote. There will be there will not be a voting process and a presentation and a document and a vote in order to get something into the sandbox. The current plan is to have two voting to your team members actors sponsors. So that basically means if you can convince two of the nine people to be on side for your project, then, you know, that ticks that box. You know, other than that, it's all in the document, but I'm not going to open the floor to comment. The playing field. So I like the idea of the sandbox better. So with that includes for inception will go away in a sandbox. We won't perform due diligence. Right. There will not be due diligence for entry into the sandbox. Hi, this is Bob wise. This is looking really good. One question just because I haven't looked through the doc here, which I'll do surely where did you land on crossover and contributor requirements for sandboxing. There are no such requirements. Yeah, I don't think it personally I don't think it's a good idea to require that. It is part of all incubation graduation story and personally I'm open to raising the bar for incubation multi companies contributing and things. But I think that we need to be super careful not to create perverse incentives at the very earliest stages. Right. Just just to be clear, I get given the sandbox, lowering the bar for the sandbox. I think that's the right call. It wasn't I wasn't advocating for one position. I was just looking for clarity on. Okay, understood. Thanks for. Yeah. And I'm sorry for all the questions. What will happen to projects that are in inception. I haven't gone through the doc thoroughly enough. Right. It'll move into the sandbox. It'll move sandbox or graduate to graduate. Thank you. Yes. Good point. In terms of the sandbox exit requirements. Is there an exit where it will move out of the CNCF as well. Chris, why don't you take that one. Right. Right. Right. Right now. No. The only exit is just being archived. Put in the attic. Your question mark. I guess my, my main motivation for that is when I saw things like donating the trademarks to the CNCF. You know, because of the 501 C three. Yep. It has exit requirements for. You can't move it back out. And so I was just curious about, you know, if a sandbox project was not successful inside the CNCF, but someone else wanted to take it out external. What would that look like? And I'm not saying that would happen. I'm just trying to poke at the edges of this. Yeah. I mean, probably case by case basis, like if for some reason something failed and wanted to move to another open source foundation, we could potentially do something there, but I treat it as a case by case basis. Do those trademarks actually need to be transferred when entering sandbox. We discussed not doing that for inception and maybe even incubation. We've decided to require it. I think it's a little bit more defensible for us, but it's up to the TOC. But the licensing terms are pretty liberal. So people can just work the project also. Correct. Yeah, absolutely. And are we going to create any rigid, not rigid is maybe the wrong word timelines around this. I mean, could have, you know, something be in the, well, we have a timeline for the sandbox before we would come up for a vote for archiving or it doesn't seem like we have good criteria on terms of timelines. It's like after a year, after six months or after three months, there's an evaluation period. There's annual reviews. If you look at the diagram for everything. So that's kind of our timeline. There's no forced timeline in terms of how long you have to stay in the sandbox. It could be infinite. Okay. Or it could be shorter, could be six months. Yeah. Yeah, it could be three months. Who knows, right? But there's no forced timeline for, you know, graduation or moving to the next level. There's just an annual review from the projects. So one thing that might be missing inside the diagram is, is that I think we, this is verbally described down below, is the notion that projects are still encouraged to be reviewed initially at an incubation level. But, you know, they might find themselves going through sandbox first. If for the lazy reader, those that just draw their eyes to the diagram initially might consider that the sandbox is, is the only path to an incubation. Although it also, I mean, it also implies pretty strongly that it is the most profitable path to incubation. So I mean, I would want us to be steering most projects towards the sandbox, making exceptions for projects that are ready for immediate incubation. So sorry, what's the intent there? Because I think Brian and I have got slightly different perceptions of it. I mean, I don't, Brian, how strongly do you feel that the, or how frequent do you think it'll be that projects skip the sandbox and go to incubation? Well, I think we're still in the process of discovering existing open source projects that are more mature. Well, we're, the reason for the sandbox is that we're also entering a phase with it, where there are a lot more early stage projects being started and developed. So I think that shift will continue to occur over time. But I don't think we're completely, we've completely discovered all of the more mature projects yet. So maybe do we want to put some language in the dock to that effect that the projects that will be potential candidates for not being in the sandbox going straight to incubation are those that have matured outside of the CNNCF? Sure. What I'm trying to do is I would like to avoid a, the stigmatizing the sandbox such that everyone wants to, wants to skip straight to incubation and effectively. This is Alexis speaking. This is going to, this is meant to be as rude as it sounds. Have you read the document? Cause there is some language about this. Yeah. I think Brian and I both read the document. I was quoting from the document. Okay. So the document tries to be explicit that there's two things. One is that the, the process is not discriminatory, meaning that the TOC will not favor projects from the sandbox just cause they're in the sandbox when it comes to incubation, but also to that the re, one of the reasons you should be in the sandbox is to get to incubation faster because you know, the idea is that these are things that are supposed to help people get that. And if that's not clear, I would like to make it clearer in the document. I do agree though that we don't want to disadvantage projects in the sandbox. So I've made a comment about this with regards to, um, I forget some other, some other issue. So we do, we do want to be careful that they're not disadvantaged that the projects couldn't do things that they would normally be able to do to, to grow and thrive outside the sandbox. Okay. Where's your comment, Brian? I'm trying to find it. Uh, may have been resolved. Okay. It's under the governance and benefits section. Okay. Well, I would welcome more contributions to this document quite frankly. I feel like Chris and I have got it as far as we can together and it needs a few more people to have a look just to get it over the line. Part of the reason that I raised my voice earlier task about, um, or to highlight the notion that folks who are just looking toward the diagram might consider that sandbox is the, the only way in is back to Brian Grant's point. Like we've been here at SolarWinds, we've been doing a fair bit of work with, uh, Intel's snap and, uh, and considering where, where his home might, might be. And, um, and, and that, that product itself is probably, you know, probably most appropriately considered as something of an incubation. And so, um, good that we've got, we've got clarity around the notion that sandbox isn't, isn't the only path toward incubation that there are to Brian Grant's point other, other open source projects that are probably at maturity level that don't start there. It is however the preferred path. Brian, do you want to suggest some, some language for the document? Alex, I'm not sure to whom you're speaking, but I think that Brian Grant's concern was just that, that the diagram was overly prescriptive. Okay. I would be happy to use the diagram. Or we could, um, introduce the direct arrow into the incubation stage. And, uh, I'll try to find some time to propose some language somewhere in the document. And if we do that, I just want to reinforce some of the language that's already there about the sandbox really being the, the preferred path. Um, it's not obvious to me, for example, that Intel snap would be a candidate for direct incubation. Cause I think we all want to get ourselves out of the problem of where we are adjudicating a bunch of projects that are relatively small projects and relatively new projects that we don't think are insignificant. But that's the problem. We at the TLC are trying to solve and I don't want to recreate that problem by implying that everybody should be going straight to incubation. So if we're going to modify the diagram to, I think we should, I just think we want to establish what some pretty clear, um, rules of thumb in terms of what kinds of projects would go straight to incubation. Okay. All right. Well, I mean, I mean, I think we do that to the, the, the, the outline incubation criteria is very helpful in terms of where, what kind of expecting. Okay. And that still applies. We'll update it as soon as we finalize the sandbox criteria. Yeah. And I think maybe, maybe if you update the diagram, just point to the later in the document where we talk about the exit criteria, basically like if you're going to go straight to incubation, you're really need to have already satisfied the exit criteria. Yeah. Got it. So here's another request to, to the people on the call, which is if there's something about the document that you, do you just feel isn't quite right or, um, could be improved, but you're not quite sure what language to propose. Please do try and articulate your question or your doubt on the public CNT of TOC list. And I promise to spend some time or Chris or both of us just trying to craft some language to reflect your concern. Comment on the docker on the list. You can put in the doc. That's fine as well. Or in the, um, in the list. Thanks. So Alexis, you were concerned that this was not ready for a vote. Um, what are some of the big gaps that you still see? Cause this to me looks pretty good. Um, I mean my modules, minor things with what are some of the big holes that you're seeing? I didn't think there were big holes. I just felt that we might have got some of the tone wrong. Uh, we might have overlooked a couple of key points that we have an opportunity now to include, uh, rather than, so I just was predicting that we probably would just need a bit more time, uh, before we actually vote on it. And, uh, I reckon, however, that having listened to what people said on the call today, that it is feasible to get further edits done. Um, let's say by this time next week and then maybe call a vote on the email list rather than on the call. Yep. Okay. All right. So let's do that. So once again, for those who are listening, um, you've got one week to voice concerns, doubts or make comments, and we will try to get them all reflected in roughly this time next week, Tuesday, which is obviously not, not a TOC call. And then we will, uh, agree informally to call a vote on the document without requesting soliciting input further input from you, which is call a vote and we'll get plus one. So not based on people's position. And if we don't get it over the line, we'll continue editing it. I think that makes perfect sense. Thanks. Alrighty. Ah, okay. What's next? Project proposals. Call for contributing. Yeah, a few, few more TSC contractors. I'm basically happy with the Nats proposal at this point. Um, I'm just looking for a few more external idols. My primary worry with Nats was that, um, people who were not familiar with messaging might have a whole bunch of questions about it. So it's really crucial that the other people who volunteered to help like, uh, Quinton, uh, Lockie and others could go and take a quick look and just make sure they're happy in anyone else. And I believe the same is true for OPA and Spiffy. Yeah. Just to be clear, this Quinton, um, we had a bunch of Huawei messaging people look over the duck. Uh, it might not be clear based on the names that might be unfamiliar, but yes, the stuff I plan to do has been done. Great. And all the, all the OPA feedback, um, has been incorporated as well, I believe. So I think OPA is ready to move forward. There's anything I'm missing there. Just you can pull up to my attention offline if you want. Sounds good, but I'm holding, uh, votes until we finalize the sandbox stuff. Okay. Um, and I had quite a few comments in the Google doc that don't look like they made it into the PR. Are we going to have a more consistent, we're going to start with the PR. So we're capturing everything there. We're still going to continue to start in a Google doc. It just seems like some of the conversations lost when we moved from one to the next. That's a good point. We should probably make sure we're going to be able to dock with this easy. We should at least copy the conversation over the PR. I think in most of the past cases, we moved the, uh, document over to a PR at an earlier stage before broad comment. The Google docs were mostly as a way just to have the collaborators on the proposal, um, assemble the, the full proposal. Together. Yeah. And then move it to a PR for general comment. Yeah. Yeah. I think in, in the next case, uh, it was kind of distributed broadly. Before it was complete. And then that caused some complications. So apologies, Aaron, for the confusion, but we'll try not to be as confusing next time. I want to make sure nothing was missed in terms of. I mean, there's quite a lot of conversation within the doc. It doesn't look like it got transferred into the PR. Um, well, you know, you're very welcome to review it and put some stuff in the PR. But I think. Okay. Hopefully someone's going to have to do that. Yep. Okay. I'll go back through and, and if it hasn't been addressed properly in the PR, I'll add those comments back in. Thank you. You know, it doesn't have to be just you, but if you could take responsibility, you know, it doesn't have to be just you, but if you could take responsibility for it and then call up the Nats people, Derek, Peter, and others and just let them know what they were doing this then, but I'm sure they'll help you. Yep. Sounds good. Thanks. Okay. Project review backlog. Chris, what are we doing about this? Yeah. So there's two things here. One is we kind of have our annual reviews. So Corey DNS is going to speak a little bit later in a call about what's going on in the past year. We have a couple of projects in particular, Prometheus Kubernetes. I believe the steering committee has recently decided that they're okay moving forward to graduate. So there's a proposal from them, kind of in their back burner to issue a PR to us. I don't know if I could speak. Okay. Awesome. Fantastic. So from our perspective, if the Kubernetes PR comes in, I'm fine holding a vote over email for graduating a few of our projects that have already submitted proposals, depending on how the TOC feels comfortable. I think both Kubernetes and Prometheus are fairly mature and well-baked. You know, they were our first two projects. I'm pretty confident they're good to go. But it's really up for you to kind of decide how you want to do this. I'm in favor of. About. If nobody has concerns about those two specific projects. Yeah. I'm in agreement. Once we get the PR, since we can notify the mailing list of people can look over. And if there's information that it was missing for making the decision, that would be helpful to work out at this stage since these are the first couple to graduate. Yeah. I mean, essentially the projects are self-declaring that they are ready for graduation and have met the criteria. Yeah. And then they are evidencing that self declaration in the PR. Correct. We are expecting them to request support for their declaration. Essentially that is what the vote is. Yeah. Right. Yeah. So in the Kubernetes proposal, for example, it will include links to. The information that demonstrates that we've met the criteria. Yeah. On a bullet by bullet basis. Yeah. The Prometheus want to read. We did that. So. Okay. So if any of these projects have any time constraints, I know that from time to time. People like to announce things. There are requests about, you know. Conferences coming up and so forth. Do make sure that you let Chris know privately. If you have worries about it. Or if it's okay on the public list, that's fine too. We should move promptly now on these things. Yeah. Sounds good. I'll wait for the Kubernetes PR and then I'll send a reminder to the main list for any further review and then hopefully call a vote maybe late next week. Yeah. So working group updates now. Ken, do you want to congratulate the serverless working group on releasing their 1.0 stuff? Yeah. Yeah, definitely. That was a. Both. I can think an interesting. Approach. To. To how the work group could have an output in the CNCF. So I want to first of all, you know. Congratulate the service work group. For the hard work that was put into the reference architecture. And we did ship that already. We also, as you can see on the slide, we put in a. Landscape as well. And the landscape is. Maybe not as. I'm not as big of a fan of the landscape as I am. The white paper, but I think it's, it's good to try to start defining. Within the framework of the white paper that we developed, what sort of projects. Fit within there. And so the next step, just step out of this is two things. One was still thinking that might be interesting to bring forward some of these projects to the CNCF incubation. Or for. Sandbox, once that gets ratified, assuming that they are cloud native. In scope and function. So. And then the second thing is we started working on a cloud events back. Which is sort of an attempt. As you guys know, events are collected and managed in many different ways across every single cloud provider and every infrastructure today. So. We're trying to cope with a kind of an event. Event master of all events, if you will, kind of let you feed in your events into, into a common. Framework for event manager management to cross multiple environments. So. Once we get that to a point where we're ready to bring it to the TLC for if you will do that. Doug, I know you're. On the causing thing you want to add to, to the white paper, to the cloud events spec. No, I think you covered it very well. Thank you. Doug has done a great job of helping us move this forward. So I want to thank Doug personally for the. Thanks Doug. And also thanks for everybody else. And especially you're on another super work into this. Sarah to. Sarah. I have a request. About this cloud events, which is that, you know, some of you may have made notice that. Kelsey high tower has been doing. Quite a lot of. Tweeting about serverless in the last week or two. And did an interesting kind of deep dive review on open whisk on IBM's blue mix platform. And talked a bit about the event APIs. And it would be good to. Show Kelsey some of this work if he hasn't seen it. And see if he as a member of the community can comment because I think it's important that. People see this work as useful. And if it's not useful, we need to make it more useful. So now that we have documents to show you, let's get them in front of people. Yeah, I can definitely do that. And the second thing I want to ask people on the TOC cool. Do you think this is the kind of work that the working groups should be doing? Is this. At least the first base satisfactory as a set of deliverables for working groups, because I know that we haven't quite figured out. Exactly. What level of empowerment. Is this. At least the first base satisfactory as a set of deliverables for working groups, exactly what level of empowerment should be given to individual working groups around. To see stuff and we're still that's something we need to figure out soon. Does this serverless working group represent a success here? What are people's thoughts on this? Actually, this is Doug. I have a question. Ken mentioned earlier, the working group coming back to TOC for review or something like that later on. At what point in our life cycle, would the TOC like us to come back? Do they want us to come back to this periodically? Do they want us to pay the TOC when we feel like we're in progress? Do you want to wait for one point over the spec? What kind of time frame are you guys looking for? Well, I think that the working group should report to the TOC, you know, sporadically every one to three months. It doesn't need to be regular, but I think what's really critical is that the working groups define their own roadmap, exit criteria, success criteria, and essentially act as a project and say, this is what we want to do next. When that is done, we will declare victory and then we may have future work or not, but, you know, our primary objective is to do this, and then maybe the working group could be, you know, shelved for a while or it could get a new objective, but it has to come up from the group. It has to be specified. These are the objectives that we want to fulfill. Okay. That sounds reasonable. And does the TOC need to approve of our stated objectives or as long as they're within the scope of our original sort of charter? Is that okay? I think I wouldn't say so far as, you know, there has to be a presentation with a vote and approvals, but I think it's important to take into account that you're not only socializing your objectives and any significant changes regularly on the main TOC public lists, so that people are aware of them and have an opportunity to, you know, viscerally object, then I think you're doing the right thing. I wouldn't, you know, look for explicit support necessarily. Okay. Sounds good. Thank you. Tell us your earlier question. I think that the white paper that was published by the committee is really important. I think that the working group is super useful just for, kind of getting everyone on the same page about terminology and direction, et cetera, for a given field. So I would encourage that as a good starting model for other working groups too. Good. I was also just going to comment that I think that it is really highly valuable to have a venue for to discuss the interoperability concerns between projects. I think we're still converging on, you know, kind of effective process around the serverless working group, but certainly it's, you know, instead of each project having one off conversations with other projects to figure out how they're interoperable, having a working group who's focused on that domain, help facilitate that conversation. I think, you know, I don't really see another place for that. So I think that's good. Thank you. All right. Okay. Ken, could you talk about the reference architecture slide please and the subsequent logic architecture? Yeah. So this is something that we, on the left-hand side of this slide is our existing in-user reference architecture. And just to kind of remind the TOC members and the, you know, it might be new to this TOC call. We, when the work group formed, I guess it was, I'm sorry, the foundation formed a couple of years ago now. We had this reference architecture in the scoping document. And we kind of felt like it wasn't really the right reference architecture. And so there was a request to update the reference architecture. And so that's, that's what we came up with on the left-hand side of it that we announced it. I think KubeCon and... Sorry. I'm the only one who can't see the presented screen. Oh, I'm just going off the slide, the slides it was sent out, slide 13. Gotcha. Sorry. Yeah, I'm not sure. Slide 13. Sorry. And so on, on slide 13, the left-hand side picture there is our current in-user reference architecture. When we put this together, the idea was this was supposed to be kind of a high-level reference architecture, not meant to be technical and not meant to be very specific or detailed. And we decided, you know, I discussed the need to kind of get to the next level of detail, which I'm kind of calling a logical architecture. That might not be the right name. And I'm happy changing names at any time. So the, this was a proposal I worked with with an interesting member from the call we had last week or two weeks ago. He reached out to me and said, hey, let's, I like the idea of taking it to the next level. And here's what I've been thinking about. And in other discussions I've had over the last couple of years, control and observe and optimize seem to be kind of a key theme that keeps coming up over and over again. And so as you kind of look at the different components or the different functions that make up kind of a cloud native reference architecture, you get these sort of boxes and that might be missing a box here or there. I'm not, I'm not trying to say this is the proposal. This is just sort of a high level diagram. And we go down to the next slide, slide 14. If you kind of take, you know, kind of monitoring service communication orchestration is sort of the three main components of a reference architecture that gets to the more technical level. Pretty much all the other components have to map to those three logical components, right. And so we're kind of thinking this is now, there now seems to be some interest in taking this forward and looking at what would be the next level of detail below that in-user reference architecture that we have for the CNCF. This seems like a good starting point. I put a couple of our projects in there already that we have. And as I said, I put, I just didn't have time to add Prometheus to this. Apologies to Prometheus not being on here, but I think this sort of helps define that next level of detail. And the point of this discussion was to say, there seems to be interest in doing something here. I'm willing to help sort of lead that discussion and schedule some meetings that kind of come up with a reference. I mean, the next level of detail below the reference architecture. I'm asking for additional volunteers to be interested in joining that effort. And then we would obviously come back to the, to this working group, you know, every two weeks with an update whenever we get to something that just makes sense to be back. And so the idea was, I don't think I need to create a working group. We could, but I'm, I'm almost thinking this is almost like a work stream outside. You know, part of the TOC effort, but not a work group within the TOC, but I'm happy to make it a work group. But that seems to be the right approach to, to work on this next level of detail is needed. Can I do think that the iterations on this are very helpful? I think that as you played them out over time, you'd almost, you'd almost say that we do have a work stream for this today. And it's, it's the landscapes. If you imagine what these take the shape of as they play out, it may become kind of one in the same. Right. And one intentionally, you know what, you know, the two starting from different places, one more from a technical perspective on capabilities and how do they interact and overlap and what a description of what those capabilities are as versus the landscaping, you know, well, it's the right way for a, anyway, I think they arrive at the same places. Yeah. Yeah. The landscape work started out of that reference architecture has some of the same, some of the other things that I think are really important are the boxes, right? And then it broke down into a little bit more detail. And so I do think there is definitely a alignment with this next level of detail and the reference and the landscape for sure. Okay. So I think the next action is to continue as you have been and we'll treat it similar to the cloud native definition of the work group. And I think that's one of the things that I think is really important is that all group of people who are dedicated to spending time on this work quickly to come up with some more fleshed out ideas without going as far as calling it a working group and then present that to the TOC. And then if we feel there's, you know, justification for creating a working group, subsequently we can do that. But let's see if we can avoid creating a working group. Perfect. And there's a, there's, I think, look in the, this isn't just to me, I've sent everyone, but Chris, thanks for saying up that issues. Yeah. Yeah, just do it from there. Call people to participate through the GitHub issue and we could start from there. Yep. Good idea. Thank you. I'm interested in being involved. Please join the discussion there. Cool. Thank you very much. So should we move on to the core DNS annual review? Yeah, is John on the call? Yes, I'm here. Hey, how's it going? Good. Thank you. All right. I'm John Delner. I'm one of the maintainers of core DNS and just talk a little bit about what we've been up to for the last year. We can go to slide 16. So it's been a pretty good year for us. We've grown a lot, our community. And one of the, one of the things we're really pleased with is that we put in a proposal to become the default DNS for Kubernetes. And we're on track for that. It's not, it's not in GA yet, but we're alpha in one nine. We should be coming out as beta in one 10. I'm hoping to GA that in one 111. I've talked to folks from a number of the different managed or other Kubernetes distributions. And everybody there I've talked to is planning on moving their cluster DNS to core DNS in their distribution or their managed managed service. So that's going well. We have a lot of growth in our Docker polls, 2.5 million polls as of this morning. And more and more people contributing, especially we've grown the contributors from the non maintainers. So we have, if you recall, core DNS, one of our things is we have a pluggable architecture. And so we've got a number of non maintainers and people building their own plugins for their own purposes. And we call those external plugins, which we, which are hosted in their own repositories and we provide a reference from our, our website on them, but had a bunch of those built this year. And we do have in our adopters file, we have seven public production users, although there's others we've talked to who aren't on the file, but SoundCloud, for instance, runs several hundred core DNS instances. And I told me I could, could say it on the call, but they haven't gotten the file yet. This is our annual review. As part of that, we can go to slide 17. We are looking to, to graduate to incubated status. And so we have, as was mentioned earlier, we have a PR out there for that. We do meet all the criteria as they're laid out there. And so I hope that we'll be able to, to have that vote soon. That's all I've really got. Are there any questions? Okay. Thank you very much. Thanks very much, John. Okay. Chris, any process steps that we should be aware of? Yeah. So, you know, per the charter, we're supposed to review inception projects on an annual basis. But it also, John is requesting to move to incubation. So we have a choice. We could try to lump those things together and just do a vote over the mailing list or separate them out. I'm not sure what the TOC refers. It seems a little bit redundant to kind of do both since they'll be so close to each other. How do you feel about this one? Sorry. The question is, should it be incubation or wait? I think incubation is fine. I think the original question around core DNS, which I think was voiced by Camille and Brian Cantrell was, you know, small one person team, not quite ready for use yet. It seems a little bit early, but I feel that it's got past all of the points it needed to and is now, you know, a full fledged project. Very happy to make it incubation and possibly graduation. If there's no strong objections, I'm fine calling a vote for it to move to incubation. And to me, that will basically nullify us having to do the annual inception review. We'll just move straight up to incubation. Sounds great to me, Chris. There's no strong objections. I'll do it. I'll call about this week. Yeah, let's go. All right, next item. I think we've just got enough time to do Rex Ray, but I'm still a bit confused about. Is this applying for incubation or inception slash sandbox now? Incubation is, is what we'd like to have a nice one. Well, take it away. Okay. Thank you guys for having me again in TSE presenting on a storage topic. I think to set some context on slide 19. It's important to note that Rex Ray has been presented. It was about a year and a half ago that we brought it to the TOC. Following that, we also presented live storage, which was really kind of the semantic layer of Rex Ray, the base implementation layer for storage features. In the meantime, when those two things happened, you know, there was an S WG that was formed by the TOC to investigate storage, storage related things. Cause I think it was generally a new topic for the TOC. And then as well, there was a group formed called the, the CSI group, which were from the container orchestrators that we're all trying to solve, you know, similar challenges that both Rex Ray and Lib storage were trying to solve. And I think you guys know the detail that, you know, CSI has been, has released to 0.1 at this point. So there, there is now a base level of, you know, contract between container orchestrators and storage providers. That works. So this, this idea that, you know, we're communicating on slide 19 is that, Hey, there's, there's challenges in the ecosystem. You know, Rex Ray Lib storage has been trying to address them for the last few years. There's definitely community momentum built around things. And there's, there's more work to do. So on, on slide 20, you know, as we move on from the problem statement, you know, the ecosystem is still fragmented today. You know, you've got multiple interfaces out there. You know, CSI has been adopted by, by Kubernetes and also by, by Mesos and soon to be by Cloud Foundry. So there is momentum in like moving the right direction, but there's still plenty of work to do to make sure that we don't continue to have this fragmented ecosystem. You know, from a Kubernetes perspective, it's been communicated that the internal volume plugins that Kubernetes has are, are, they're looking to eject them from the code base and they're looking to replace them with these CSI plugins. But one of the questions becomes like, how does that happen? What's the process and what, what's it going to take? And I believe pretty strongly that, you know, there's in building these plugins and making, you know, really good CSI implementations. There's a bunch of common code or redundant efforts that all these plugin maintainers have to deal with. And, you know, it's very important for them to be accepted and replace the existing plugins that are inside of Kubernetes that this experience for, for the operators needs to be really good. And I think that in order to get there, right, it's going to take some type of a framework where we can have collaboration among, you know, the source plugin providers to make sure we minimize redundant code, ensure a great easier experience. And that's that I think is one of what we need to get to to make these operators trust the CSI plugins and to get to where CSI is accepted as more of the industry standard. On slide 21, you know, I feel that, that Rex Ray is a great fit for this category to provide a, a place in a project for the industry to, to collaborate on as a CSI plugin implementation. So it is, it's job is pretty simple, right? He's going to help in developing the plugins so that you can provide, so it can provide a certain set of this common functionality to all the plugins that are developed. So from a, from a cloud native consumer perspective, the value is that there should be better user experiences with the plugins that are developed using this framework. And so the users are going to be trusting these implementations that will be using CSI quicker from a provider and operator experience. These are people that are actually going to be deploying the Kubernetes clusters or other cluster orchestrators. You know, they're going to have a pretty seamless deployment experience. So they're going to have consistent configuration, consistent packaging. They're not going to have to read a lot of documentation every time they pick up a new CSI plan. From a, a storage company or storage project perspective, right, they're going to be able to implement the, the basics of what CSI defines or the basics of what their storage platform needs to be CSI compatible. And then after that, they're going to get a bunch of features and integrations for free. So it should be the, you know, the lowest friction path to creating a CSI plugin for them. Additionally, there's going to be interoperability that's provided for backwards compatibility. So in this ecosystem, you know, the storage companies need to focus on a bunch of different integration points and that doesn't end just today. Just because CSI came out, they still need to maintain compatibility against existing integration points. And so, you know, one of the other things that Rex or you can provide is this interoperability layer. So as you build a CSI plugin, right, you're, you're actually compatible with, you know, Docker's existing volume interface through that interoperability layer. So a few key points as to why storage companies or projects would be interested in, in collaborating on this kind of project. Rex has already got a ton of existing integrations. So as a framework, it's got up to 15 different integrations that it ships with today. On slide 22, we're highlighting the existing user experience with something like Docker that Rex already provides for all of the storage platforms that it has integrations for. So here you're seeing AWS, GCE, SAF, like a bunch of different platforms that are all very common. And when someone goes to use a managed plugin through Docker today, you know, they go and they have a single command through Docker that goes and deploys, configures, and gets a plugin up and running. And it's, it's that kind of user experience that I think is going to be very, very important to deliver to someone who's going to be using this CSI plugins. And the, you know, the, the situation becomes a little bit more complex in the CSI world because in that space, like the CEOs may have different packaging and they may have different, you know, methods of getting things up and running. So Rex Ray can really fill that void to, to provide value at the CO level. On slide 23, you know, I think it's, you may be kind of scratching your head at a certain point saying like, hey, I thought the CSI is going to solve, you know, the, the fragmentation problem in the ecosystem completely. And, you know, the reality is that there's, there's many different layers of code. And there's many, there's a lot of things that you would consider redundant and common across some of these layers. And so what we're trying to communicate on slide 23 is, you know, here's the different pieces and here's where Rex Ray exactly fits in. So first of all, you've got the CSI spec that, you know, it's great to find that contract between a storage provider and a cluster orchestrator. And then because of GRPC, you have your CSI API bindings, which make it, you know, somewhat easier to implement. But then you have to start implementing and like, you know, enforcing what the contract says within your code. You've also got to validate kind of end to end that the spec actually works as it's supposed to. So above the CSI blindings are, you know, unless you see it below, but there's these implementation libraries that are emerging that the community is starting to work through and collaborate on. And one of those being go CSI and there's others, especially a part of the Kubernetes implementation. And those are really specific for, hey, if I'm implementing CSI, these are the much needed things that help me, that are defined by the spec that helped me create a basic plugin. And that might be boilerplate code, it might be logging, configuration, where CSI really comes, or where RECSWARE really comes into play, you know, in this perspective, is that it's going to help bring to the table what's not defined in the interface spec. Maybe that's the CO specific packaging. Maybe that's the documentation that helps you understand how it runs with the CO. Maybe it's end-to-end CI CD and deployment and, you know, artifact handling for any of the plugins. Aside from that, you've got things that are important to people who want to pick up these plugins. Maybe that's the handling availability of scale, security, you know, lots of other stuff. Additionally, there's CNCF projects that are important for these plugins to create a great like cloud-native experience. So maybe it's integration to SED, like any of those projects that all requires code. So RECSWARE is really meant to handle the things that are not in the CSI spec but are important for creating a great user experience with these plugins. So how does that look like in terms of how we create this native CSI plugin? The message is, you know, you build a native CSI driver and RECSWARE's back-end is any of these native CSI drivers. So focus on the key platform capabilities that you need within your CSI driver. And you ship that as a go package. And then RECSWARE actually uses these CSI drivers as its back-end and provides all the extra value ads and feature functionality that I've been describing. So it's related to my plugin application. Who is you referring to in those statements? Anybody who's building drivers or who's a storage project or platform that wants to be relevant within the CSI ecosystem? Okay, so it's storage people. Yep. And there's three audiences. One is the end users who really shouldn't know much about CSI. They just know that they have their platform supported. You've got your operators who are just deploying these and the operators care about a great user experience from how they actually get these plugins up and running. And then the other audiences, the storage providers and projects want to be relevant in CSI. So this slide is speaking to how do I build a driver? What is it about this native CSI implementation framework that RECSWARE provides? So as a project, RECSWARE has been on a pretty steady release cycle since 2015. This is slide 25. So we've had about 78 releases activity-wise, pretty consistent repo activity, whether it's the events generated through GitHub or whether it's the downloads through BingeRay or Docker Hub. So very steady amount of demand for the project. On slide 26, we speak to the collaborators and pull requests. So in addition to downloads, kind of on the other side of it, we've had plenty of collaborators and pull requests that have gone through the project and a pretty steady amount over the past couple of years. I expect that RECSWARE's importance in the ecosystem is going to increase dramatically at this point. As of two years ago, three years ago, actually when it started, it was really a Docker project for managed plugins. And as CSI has emerged, it's now become relevant to everything. And especially as Kubernetes starts ejecting these drivers, then that's even going to be more important. And so tracking-wise, we've had a steady increase in GitHub stars up to about 1069 at this point. On slide 27, we're speaking to the known users. Obviously, on the right side, there's lots of non-public users that you can address by name, but you can see the categories that they're in. But on the left side, we've got plenty of public users. So whether it's being the default implementation for MesoSphere, so all MesoSphere deployments that ship RECSWARE by default for storage primitives, whether it's in the Rancher catalog or also available through SAPI-O. From a corporate perspective, we've had plenty of collaborators, whether they're contributing plugins or speaking publicly about using it. There's the list of different corporations. On slide 28, I actually opened up a thread ahead of time to discuss with the community, to let the RECSWARE community know that they were thinking about contributing it to a foundation. And here we had open support from other companies that want to collaborate on it if RECSWARE was inside of a foundation. So you've got Diamante, MesoSphere, Portworx, Rancher, SolidFire, StorageROS. These are all companies that wish to have a foundation so they can collaborate on this CSI implementation. So finishing up on slide 29, I think that storage is a critical component for cloud-aid environments. I think that being one of the major challenges that I started out with in these cloud-aid environments addresses that maturity-wise, people are thinking about using these environments in Kubernetes, et cetera, for more critical workloads. So this area is kind of maturing and they're asking tougher questions. So I think we're at a tipping point when it comes to the spanning of types of applications that are relevant in cloud-native. For storage companies, it's very competitive. And I think that one of the things that's going to help CSI mature and get to where we can eject plugins from Kubernetes is that we need a project that the storage companies can collaborate openly on with open governance. And I think that's just one of the key things. So with that, I'll wrap it up here. We're out of time, Clint. Thank you very much for that. That was very helpful. I have a few quick questions and then I want to just ask Chris something. So number one, just as a member of the audience, what your explanation of what it is could have been a bit clearer. And that should happen if you go to the next stage. Who it's for, what problem it solves, because it shouldn't be something which just solves a problem for the storage vendors. What's the end-user benefit? It's not there, it's not super crisp. The other thing is what are the alternatives? What's the devil's advocate case against Rex Ray? I didn't quite understand that. And again, I've said many times that I'm a storage idiot, so maybe I'm missing something, but it would just help to be a bit more simpler and simplified in terms of your explanation. Other than that, I think that we don't have time to call for a vote to proceed. So I'd ask people to put questions to Clint on the public list, please, about Rex Ray as a follow-up to today's presentation. And then maybe if we start to see consensus emerging, we could ask it to do a written proposal. Is that okay as a next step? Yeah, if that's what you want. Yeah, could someone please start a thread? I do have some follow-up questions. Thank you. Could you start the thread up, please? Sorry to be useless. I've got to run as well. Yes. Okay. I'll set everybody. Thanks again. Thank you.