 All right, well in that case, let's begin. So the first thing we had on the agenda was the the end user survey, which we have now converted into a survey monkey survey, which we emailed out yesterday. There were a couple of bits of feedback which have now been incorporated in there. And if there are no other sort of significant objections, we're planning to send the survey and the white paper to the end user forum this week. And Cheryl will be will be will be helping us with that. And I'm putting like a covering notes with it. And I'm suggesting that we put an end date of the 10th of May for responses to the survey so that we can collect the information and have something to discuss for kube kind of possible. Does that sound okay with everyone? Yep, sounds good to me. All right. On that on that note, we we also got a slot with the end user forum. Unfortunately, the the the first first slot that was available was the 9th of June. There was an earlier slot in May, but it's conflicted with the coupon Shanghai. So we moved us to the night of June now, sorry, the night of July. Sorry. Well, kube kind of Shanghai is in June. So that's right. Sorry. Yeah, it was it was if the first slot was the 25th of June and conflicted with the Shanghai event. So we'll get the night of July instead. The next item on the agenda that we had was to discuss feedback from the the open ABS discussion and some of the points that Saad had raised in a number of emails to this and the talk mailing list. I don't know, Saad, if you want to maybe quickly summarize some of those discussions. So I don't think I have any more outstanding concerns. I think I was mostly just confused about the process and why we were doing this. So to summarize, I think one was around. I think it all just spurred from I saw the presentation. I saw the discussions going on if we're going to be inducting EBS open EBS into the CNCF. And my first question was why there are lots and lots of file and block storage systems out there? Why are we picking this one? What is special about it? What is what is the reason behind doing this? So then that kind of led to another question, which is what is the process of induction? And actually it led to a third question, which is what is the purpose of this group, especially now that it's turning into a special interest group? So I think the answers that I got, I am mostly okay with. It sounds like there are different levels of incubation within the CNCF. The bottom most level is called sandbox. And as I understand it, the steering committee for the CNCF wants the sandbox to be as low a bar as possible to help incubate new types of projects that need help, that need a community to kind of foster their development in. And the entire purpose of this sandbox is not to have a very high bar or try to be very selective in terms of who gets in or who doesn't. And the other important thing to note is that the sandbox is explicitly not endorsed by the CNCF. So that kind of changes things. The induction of open EBS into the sandbox isn't really an endorsement by the CNCF. So the question of why are we picking this project, it is a little bit less relevant. Yeah, just to add a little bit to that, you know, there was there was a lot of first debate around what the criteria are for, you know, the different levels within the CNCF projects and the sandbox included around last year. And one of the, you know, the major points was that the sandbox was about, you know, projects attempting to build the community as opposed to the CNCF endorsing them, as you mentioned. And there was there was a little bit of sort of, I guess, TV issues around a couple of the first sandbox projects that were that were included, because the CNCF did did end up actually doing some press release or something like that. But I think, I think that kind of sort of took that feedback on board and now it's fairly clear that, you know, the CNCF is actually endorsing the sandbox projects per se, and they're not receiving, you know, publicity or marketing benefits. It's more around building the community and kind of giving the project a foundation to grow where it can potentially then move up to the next year. Yeah. Yeah. No, that makes sense to me. I fundamentally still think that's a little bit of a strange direction to go in, because as soon as you have, you know, any kind of benefit that's being given by the CNCF to a project to a certain extent that is an endorsement. And, you know, that is, and we should have, I think, a higher bar to provide that kind of endorsement. But I think it's a fine line. So I can I can completely by the argument that, well, the benefits that are being given here do not justify a, you know, a very high scrutiny for the projects that'll get in. That's not the purpose of the sandbox. So I think that makes sense to me. Well, I would just like to say, I agree with you that there is an implication maybe not of endorsement, but certainly of providing aid and taking under their wing a project. And, you know, we need to be aware of that. And although the, you know, having a low bar is good, there still needs to be some kind of bar. And we probably should still continue to have some discussion on where does that, where is the level of that bar, right? And I agree also with the validity of the first question, which is why this project, right? Is there a need ahead of time that's been identified, you know, and have we sifted through other projects that might also support this need? You know, is that the process? And I was unclear too, reading through some of the comments in there. So yeah, I can respond. I can respond to that set of questions, which, which I wanted to do anyway, because I think there is some confusion, which I wanted to make clear. So I was pretty actively, it's Quinton speaking, by the way, formally on the TOC. And I was pretty actively involved in defining these tiers and having this conversation, the TOC. I think this notion that we need to kind of compare all of the alternatives and pick the best one is, is, is not right. So there is no such requirement. And there is actually a counter requirement in the TOC that we do not pick winners. But that actually any project can come to us, we have a set of criteria that they need to fulfill. And if they fulfill those criteria, then they get to live in the CNCF. And the criteria are actually fairly simple. For sandbox, they're like, essentially, are you, you know, interesting to the CNCF in the future at some point, maybe you don't have to have any code, you don't have to have anything, you just have to have a plan to build stuff that we think is interesting and sort of cloud native-ish. And that's by design, very low barrier to entry, etc. Incubation says that you have actual momentum, you have an actual thing, and it's actually used in production by some number of companies. And graduation, you know, just raises that bar, you have multiple contributing companies, you have a larger number of production use cases, etc. And nowhere in there does it say that you're the best in your category, or that you're better than somebody else, or anything like that. So I wanted to just make that very clear. The fact that Open EBS is in the CNCF, I mean, it happens to be in sandbox, so it's kind of even less relevant. But even if it works in incubation or graduation, does not say that it is the best, you know, distributed block store out there. It just says that it is a distributed block store. It is used in production. It does have, you know, various characteristics with regards to contributor communities. And the owners of the IP decided to donate it to the CNCF. That's what it says. Does that make sense? That's a lot more clear. And I appreciate you sharing that because it does clear things up. The only hesitation that I would still be left is making sure or, you know, is there a way that we avoid nepotism in the process of bringing projects into CNCF so that it's not just a cozy little... Makes perfect sense. And that's why all of the evaluations are done in public. And to be clear, not all of these are like selected by the CNCF. So OpenEBS actually came to the CNCF and said, we want to donate our project. We did not approach them. And our job at the CNCF in that case is to say, do you fulfill the criteria that we have specified for sandbox or incubation or graduation? And any project can come to the CNCF and say we would like to donate our software to the CNCF and accrue the benefits that come with that. And if we decide not to do that, then there's usually some kind of public evaluation whereby it either gets voted on by the TOC or they fail to find sponsors in the TOC to sponsor them. And usually there's some reason behind that given. And if not, you can ask the TOC why did nobody sponsor this project? That would be a perfectly reasonable question. It can be asked in public and hopefully somebody will be in answer. Does that make sense? Yeah, that clears a lot of things up for me. I was confused going through the thread and I think you straightened me out. I appreciate it. Awesome. I mean, what it does highlight, sorry, Xing, let me just make one last comment. So what it does highlight though is that the logical end point of that is we're going to have many, at least several of similar or I hesitate to use the word, but competitive projects in the CNCF. And we already have that in various spaces. The service measures are one example where we have several. And it is incumbent on the CNCF to make it clear what the similarities and differences are and to enable users to be able to choose between them. And so we do need to take that fairly seriously. Whereas if we only decided we had one block store, then that's the block store that the CNCF proposes because it's the only one we have, which is not the case. Sorry, Xing, carry on. Oh, I just have one question. Do you have an example of a project that wants to join Sandbox but got rejected for some reason? Yes, I believe there are some. Some of them, for example, I mean, if you look at the CNCF website has a very clear definition of what cloud native means. And we kind of fundamentally believe that cloud native architecture is, you know, compatible with the CNCF's mission. And if you come to the CNCF with a project that is fundamentally not of that nature, it will be rejected on that basis. I mean, to use a sort of corny example, if your software only deploys on a mainframe, a fairly mainframe, somebody will say that is not a cloud native approach and therefore does not belong on the CNCF. Got it. Thanks. Yeah, I think the challenge is that we need to get better around educating the CNCF members on landscape and options and that sort of thing, right? So we kind of are going to be in a bit of a scenario as the CNCF grows, where in the early days there might only be one or two projects in a particular category. Just because of timing or because of, you know, it's just early days, in which case, you know, you're potentially promoting one over another. And on the other hand, you might end up in a position somewhere down the line, kind of like what happened with the Apache Foundation today, where there are so many projects and so many things to choose from, that people will need just their guidance as to what's on the landscape and what things are used for what purposes. So I think that's something we need to be aware of. I'm not sure there's sort of any obvious solution other than increasing awareness of different options on landscape. Yeah, I agree. We're 20 minutes in now. We got a few other things. That sort of adequately addressed people's questions there. I think that was a useful conversation and thanks for bringing it upside, because I don't just to be clear, your confusion around this is not unique. The similar question comes up, you know, fairly often. And I think it's, you know, the CNCF has actually failed in some respects. I'm not making it clearer. And that's a well understood problem. And when the people are looking to solve. Yeah, thank you. Thank you for clarifying that it does explain things a lot and what's going on and why things are happening. I think fundamentally, I still disagree philosophically with that direction. I think we should be the CNCF should cultivate a ecosystem of projects that are more complementary to each other and be more selective. But I can also understand the draw of making the ecosystem more open and actually just say, Hey, there's all of these options and we'll help you figure out which one's best. So thank you for taking the time to clarify that. Sure. I can respond very briefly to that because that's a reasonable point of view. You just pointed out the counter argument is that it's not usually very successful to try and pick winners. It's much better for the winners to emerge from the ecosystem by virtue of, you know, ending up with more strong contributions and lots of use. Try and, you know, make those determinations ahead of time and say, you know, this particular project going to be the most successful, you know, box door or service mesh or whatever category you like. Statistically, most people are wrong. So we kind of avoid making that mistake. And we just say there are a bunch of them and over time, the community will decide which ones to use and which ones to contribute to and those will become the strongest and we don't even try to predict what that will be. Yeah, no, I completely agree with that. But what I, if I were to make the decisions here, what I would do is say that for, in order to get into the CNCF, you either have to have just, you know, pure adoption where you're the clear winner in this space. So that makes you, that that is the criteria for you to get in or there is a strategic kind of whole a gap where it's important for the CNCF to have a project in a space but none exists or there's one that's kind of fledgling provides support for that. But it does leave a gap. Like you mentioned for projects that are brand new, they're not clearly the winner. There's competition in that space. Where do they go? Personally, I don't think they should go into the CNCF if there's something under the Linux foundation or another kind of some sort of like if we could shift the sandbox somewhere else, remove the CNCF branding from it, let that be kind of an incubation center and then let CNCF be the kind of cultivated catalog of the products that complement each other within the CNCF ecosystem. I think that would be a best of both worlds approach. Okay. Yeah, maybe we should pick that up as a conversation at a KubeCon or something sometime. It's like a longer conversation. Let me see your point. And I think there, I mean, it's not clear to me that that would be strictly better. What you proposed would be strictly better than what we have. I do think that we do need to be very clear about the branding. And that that was a mistake that the CNCF made in not drawing a clear enough distinction between sandbox and the other levels so that it became very blurry whether this thing was like this super successful, well adopted, well supported project, or it was somebody's idea that got into the sandbox. And that that messaging has been made a lot clearer since then. But, but, you know, some of the damage was already done. Yeah, I leave conversations up. So thank you. Awesome. I'm just going to sort of extend this conversation too much because he said we've already spent some time on this bit. I do really like Southside idea about products that complement each other. And somehow I think maybe that might be worth the discussion either, you know, some other meeting or perhaps in a KubeCon event where it would actually be useful to talk about how products make the sort of the the end to end stack of the cloud native ecosystem better. Like, you know, for example, if if products, you know, make Kubernetes better or they make logging for Kubernetes better or they make service measures or security or whatever better, that's probably more valuable and more CNCF friendly than say, I don't know, something that that that makes some sort of proprietary orchestrator better, for example. I mean, I think there is value in that because because at the end of the day in the CNCF is here to make the adoption of cloud native technologies more successful and more and more pervasive. And therefore, there is value in making sure that there is some sort of sense to the end to end stack. So products working together and products complementing each other should be a goal that we, you know, attempt to move the needle on through through some process here. Yeah, absolutely. I agree with you. And I think a lot of that happens naturally. But yeah, more discussion for sure, we can we can take take it up elsewhere. Cool. Okay. The next thing we have on the agenda, which is probably more significant for the working group today is that the fact that the working group is transitioning to a CNCF SIG, the proposal for CNCF SIGs was was voted on and approved a number of weeks ago now. And Quinton has drawn up a draft charter which is put into the agenda for the for the day's meeting. Quinton, do you want to quickly just run through this? Yes, I can do that if people think that would be useful. Perhaps I should present. There you go. Can everyone see the document? Yes. Okay. This does not represent months of work by any such imagination rather a couple of hours. I tried to keep it as simple and stripped down as possible. Otherwise, these things can become pretty unwieldy and philosophical and whatever. What I try to spell out is what we consider to be in scope and out of scope as perhaps the starting point. And then turn that into a, you know, shortest possible mission statement. And then just be clear with how we overlap with interface with and otherwise interact with related groups. And then the basic operating model, which is actually covered in the SIGs proposal. So all I really wanted to call out was the stuff specific to our SIG that I think in on principle, we just follow the standard SIG operating guidelines and pick a few people and that's about it. And yeah, we can go into that later. So maybe talking about scope would be useful. So we consider to be in scope any storage systems and approaches suitable for and commonly used in modern cloud native environments. There's a link there to what a cloud native environment is as defined by the CNCF. We can jump there if you like, but it's fairly self-evident. And especially where these differ significantly from storage systems and approaches previously commonly used in traditional enterprise data center environments. And these areas are not already adequately covered by other groups within the CNCF and there's detail below. So that was kind of what we consider in scope. And we strive to understand the fundamental characteristics of different storage approaches with respect to the various different characteristics and relate these to the suitability to various cloud native use cases with a reference to the white paper. So does that sound reasonable? Is there anything there that anyone has any violent disagreements with or thinks is missing? Should we be, sorry, I was actually going to jump to the next one, the out of scope. Sure. Do we want to consider databases out of scope? I think for the white paper we actually out of scope them for the initial for the initial white paper, but in scope them in general for the storage working group. They are officially in scope for the working group definition as defined by the CNCF TOC. So after working with the SIG. So maybe we should actually... Yeah, I mean, I kind of made a point of trying to keep the in scope stuff short. I didn't want to go to block stores and object stores and this kind of store and key value stores, because as we go into some length to explain in the white paper, some of these things don't necessarily properly define something. There are interfaces, there are implementations, there are properties associated. You can have a highly durable object store or a totally not durable object store. So object store doesn't necessarily mean what you think it means. But for that reason, I didn't explicitly call out databases, but they are implicitly in scope. Okay. Is there going to be like a SIG workloads or SIG apps or something for the CNCF? Yes, absolutely. There is such a thing. I... So at least on the Kubernetes side, traditionally we've said, hey, databases are the responsibility of SIG apps. I'm not sure if we want to make the same distinction here. If not, that's okay, but maybe it's worth being clear and we don't have to explicitly define it as part of in scope or out of scope. I was kind of just looking at the examples that you have below. Maybe we could add a database as an example if it is within scope. Sure. I've just flipped across to the actual SIG definitions here. And so to answer your one question, application development operation and testing is a SIG. And it covers everything to do with, you know, PAS, serverless operators, anything to do with application development, etc. And has a relatively small number of projects. I imagine that will grow. And in particular, this kind of pipelines and workflows and all that kind of stuff is is hotting up a lot. Storages, block, file, object source, databases, key value stores, etc. So that, you know, is officially delegated to us. Okay. You know, we can obviously complain about that and we can say we don't want to SIG apps, but I think it fits fairly well in here. Yeah. I think conceptually it does. In terms of expertise, I think the people who tend to be experts in databases are not necessarily experts in the lower level stuff or vice versa. Yeah. That's something we'll need to address. You know, we need to find experts and get them involved. Yeah. So that third tech lead, if we could find someone who's familiar with database, that'd be awesome. That's a good idea. Awesome. Actually, actually, Shang Lee, he has, well, he's a maintainer for EDCD, right? So he has expertise in that. That's true. I mean, it's not technically a database, but you know, we do have TIKV and the CNCF. So that's a, you know, more classic distributed database. And also Vitas, as for the MySQL. That might be an idea. Maybe somebody from the test community might be interested here. Yeah. That'd be great. Okie dokie. So the stuff out of scope, I sort of somewhat jokingly said anything that's not in scope is out of scope. But in particular, I think we don't really, you know, go into researching nonvolatile memory or any of the sort of underlying hardware devices that actually store the stuff. We don't spend a lot of time on that other than to the extent where it, you know, has fundamental impact on some of the cloud native specific stuff. I tried to make that as short and understandable as possible. And hopefully that makes sense. We don't get too carried away with authentication, authorization, accounting, auditing, etc. All of these things obviously apply to storage systems, but there is another SIG called Security that that is fully occupied with worrying about such things. So yeah. Quinton, for that first point, is it worth making it a bit more explicit and kind of saying the focus is on software and services as opposed to hardware? I didn't want to go quite that far because I don't think that's true. I think it's perfectly reasonable to have, you know, a honking grade storage cabinet or several of them in your private cloud, for example. I don't think that is out of scope, but figuring out how a spinning disc works or how an SSD works will spend a lot of time doing. So that's the distinction I had in my head. I don't want us to preemptively exclude non-software based storage solutions that can in cloud native environments. I'm open to people objecting to that quality, but that was my point of view when I wrote this down. I support that fully. And maybe we can read a word that's likely to make it a little clearer. I think the distinction... So I was actually referring back to this statement of where these differ from storage systems and approaches, blah, blah, blah. Now, you know, hard disks, SSDs, NVMe, et cetera, they don't look any different in cloud data centers than they do anywhere else. So they're relatively less interesting. There are other organizations that spend a lot of time designing and figuring out how this drive should work and how SSDs should work, et cetera. And that's not what we spend a lot of our time on. That was the point I was trying to make. Make sense? Yep, make sense. Cool. So, you know, the other ones are all basically areas that are already adequately covered by other groupings in the CNCF family. So, CNCF security is one example. CSI is another example. And storage abstractions and APIs for container orchestrators fit within those container orchestrators. So Kubernetes obviously worries about that stuff. So we're not going to try and replace or duplicate any of these existing functioning groups. Make sense? Yep. How about disaster recovery backup, backup software, that sort of thing? Where would that fall? That's a good question. I definitely think data redundancy. So disaster recovery actually covers much more than storage. It's more about sort of high availability of services in general. As it pertains to off-site backups and all that kind of stuff, I think that is in scope. I mean, that's explicitly what things like object stores typically do is replicate their objects to multiple physical locations, et cetera. So to that extent, yes, I think they are in scope. Yeah, I would suggest that data protection in general, you know, whether it's snapshots or backup software or replicas or whatever else, those kind of all fall within, you know, typical technologies that are used in storage. I think they are kind of gets into a bit of a gray area, especially when we're talking about cloud native, because it probably has overlaps with sort of federation and multi-cloud and all of those kind of areas too. Yeah, disaster recovery normally covers more than just data and storage. It's usually entire, you know, replicated data centers. It's a good question. Where does that fit in the current SIG landscape? And I don't have an obvious answer to that. I mean, there is this. So we have, we have a, we call the core and applied architectures, one of the SIGs. And that is intended to cover the container orchestrators and specialized instantiations of them. So things like cluster federation, edge, Kubernetes and edge environments, those kind of things. So it sort of fits in there. And we could certainly talk about the data and storage aspects of disaster recovery in this group. Yeah, I wasn't trying to quiz you on it. I just was bringing it up because I know that's something that would eventually come up, right? Make sense. Yeah, sounds good. We have to cover that in the white paper. We covered that. We did. We talked about, yeah, we talked about the carbon recovery and those are all in the white paper. So should be part of this. Even if anything go beyond it, then maybe another group can take a look as well. But yeah, definitely there'll be storage area. And from the software side, is there a distinction made about how we're working with the actual storage piece? If we're talking about software applications that do backups and that sort of thing, this group would be covering just the function of putting data to disk, right? That's not within our scope to deal with the application backup application. Yes, it's always, yeah, there's a boundary somewhere. I think it should still be responsible of this group. But maybe we can work with another group on this. Yeah, I was going to suggest a similar thing. I think there's an overlap between application development and storage there. And I think we need to just sort of call it out. And I can add it here to the, how do I do this without messing up your comment? I think we can do that here. We need to add a, oopsie, really messing this up. I think I watched your comment there, Shing, but we'll fix it up afterwards. I think we need to add here cncf apps. All of that. How applications use storage. That makes sense. I'll flesh out the details, but I think is that what you were referring to? Exactly, yeah. It's something I think we should definitely focus on and then also should have some understanding about not getting sucked up into app dev and how these applications are going to work in terms of distributing, managing distributed workloads and that sort of thing in terms of how a backup software would do that across clusters, across data centers, that sort of thing. That to me seems like more of an application specific thing, whereas the storage piece of it writing the desk would be where I feel like this would be a focus for us, right? I think there is increasingly an overlap there. I mean, I think when you look at things like HDFS and Hadoop and Spark and many of these things, the line between the storage system and the application is quite blurry in some cases. And I don't think we need to be too prescriptive about saying, oh, that looks too much like an application. We don't want to talk about it. My pragmatic approach is if there is already a group that is actively discussing this stuff or has a strong interest in taking care of it, then we should be comfortable deferring to that group. If there is no other group discussing how applications that need to do persistent state are being architectured, if that's not being covered somewhere else, we need to just talk about it here until a better home emerges for it. What I don't want to happen is for all the SIGs to defer everything to some other non-existent SIG and then have big holes in there's actually nowhere reasonable that you can have this discussion because like everybody's referring me to everybody else. I think this is an area that actually deserves some work because we're kind of moving, right? In older environments an application was kind of built around the storage environment and now what we're actually seeing is a more composable declarative kind of architecture where storage works for the application rather than the application being built around the storage. I think that particular use case is really important because more and more that's actually what's driving the changes to what defines cognitive storage around the composability, the API, the orchestrator integration, all of those sort of things. So I think that kind of is sort of important and it would help if we sort of help to define some of that. I fully expect that we're going to get some feedback from the end users there. Yeah I think I agree with Quentin about if there's somebody already working on it. Let's let them own it. To that point, Kubernetes Storage SIG and Kubernetes SIG apps have been working on coming up with kind of a holistic story for snapshotting and backing up not just volumes but also applications and it is a cross SIG collaboration. Thinking about what is it going to take not just to make sure that my persistent storage is backed up and recovered but also the entire application as a whole. SIG apps are going to be putting out a cap soon for that so keep an eye on that if you're interested but some of this is being discussed in those SIGs at the moment. Yeah that makes a lot of sense. Maybe this is a good segue into our mission statement here and hopefully this will address some of these things. So what I kind of proposed as our mission statement is to enable widespread and successful storage of persistent state and cloud native environments through the following approaches. Providing valuable and objective information to the TSE end users and projects regarding areas considered in scope. Collaborating effectively with other related groups and that's the groups I enumerated below and I'm sure there are going to be others and we should actually add there that this is not an exhaustive list and helping to maintain the continued health of CNCF storage projects and identifying and filling gaps in the landscape of CNCF storage projects. So does that hopefully that makes it clear that we do not plan to you know replace any of the existing groups there are groups that are already dealing with some of the areas that are in scope for us and we're explicitly going to collaborate with them and not try and compete with them. Yeah now I agree with that. I think in all of these sort of things we just need to keep it pragmatic and practical right. It's about moving the needle forward and not not sort of just theorizing about stuff for the sake of it. And then oh so and then yeah unless there are more discussions about the mission and in and out of scope and the other related groups I've kind of stuck my feelers out and some people have thrown in their their hat into the ring to volunteer as various roles. These are the ones that I have so far. This is not intended to be an exhaustive list and if anyone else is interested please do put your hands up. Ultimately the TOC will decide who these people are but obviously if we can come forward with a bunch of people that we think are well suited to the job and who are happy to serve in these roles it makes the TOC's life a lot easier. So these are the currently the people I've spoken to. So Jiang is is officially the TOC liaison and I've been communicated with him about putting this charter together and various leads. Alex has volunteered to be a co-chair and I'm happy to be one as well if you want me. We need some more. Tech lead Saad has volunteered. I think he would make an excellent candidate. Xing is also volunteered and there is space for some more. So if you know anyone else we mentioned tonight that somebody's rearranging their house in the background there. We mentioned that it would be beneficial to have a database expert perhaps as one of the tech leads. Neither of which Saad or Xing I think call themselves database experts. Correct me if I'm wrong either of you. I've actually reached out to some of the people from Rook to find out if they're interested. Not that they're database experts but they might be the right kind of people and I agree we should talk to perhaps TIKB and or the TES and find out if anyone's interested there. I can reach out to the Kubernetes SIG apps folks as well to see if anyone there is interested. I know they've been working a lot on database operators as well. There we go. Yeah that'd be useful. If we're still looking I can send a note out to my friends over at Red Hat and we've got some people on on database here but I've got a couple of friends at Red Hat who are probably better suited to participate here. One thing I would caution us regarding databases and I think the SIG in general is that there are a lot of you know I'll call them traditional big iron relational database kind of people out there who maybe are not familiar with newer database technologies or less familiar with them and I think we need to make sure we don't end up with only uh traditional database experts. I think we either need to have people have you know a broad set of experience and skills with both traditional databases and the sort of more modern ones like TRKV and Spanner etc or we at least need to have both groups of people represented here otherwise we could end up with a a little bit of a sort of skewed perspective. It's my opinion. Yeah that's probably fair. There was quite a lot of contention in the CNCF at the time of the test coming in that it's basically MySQL and people were saying well you know MySQL is not cloud native and all that kind of stuff. So there's a little bit of optics here we need to just be aware of. You don't want a bunch of MySQL only people or Postgres people to be the only people representing cloud native databases. Okay cool. Quinton I mentioned in the last meeting that uh that I could I'm happy to throw my hand up as a volunteer as well if needed. How do I get a hold of you? How do I reach out to you? Oh sorry yes I think you actually sent me an email and got buried in all my other stuff. You did the right thing I just need to go and dig it out. I think what we're probably going to have to do is I think anyone who wants to put their hats in the ring here should just put you know at the end of the day as I said the TOC is going to choose these people and particularly if there's more than the number that we require there's going to be some kind of filtering process. So I would suggest that everyone put a very brief resume together just explaining why they think they would be suited to uh whatever position they're volunteering to fulfill um to to enable the the CNC sorry the TOC to to sort of make a a sensible call there. I would you know one thing I think that is a bit of a sole point in general across many CNCF projects and the TOC and CNCF in general is you know people who people who have a history of actually delivering stuff are very strongly favored. It's great to have tons of historical experience but at the end of the day if you don't have the time availability or the inclination to to actually deliver the stuff that needs to be delivered you're less useful than the people who actually crank out you know documents code evaluations what whatever the thing is that we're looking for and this is not you know in any way pointing fingers at anyone in particular but just highlight those in your in your biography to make sure that people are aware of you know the stuff that you've actually delivered in the recent past particularly if it's in the context of the CNCF that would be great or the Linux foundation or related areas. Okie dokie anything else to discuss we've got uh what's five minutes left I think we covered everything that we had on the original agenda so that's good awesome um so is it safe to say that this charter seems to be uh fairly well supported by this group uh and they know you know hugely contentious parts of it or anything that there are major disagreements on is that an accurate assessment yep sounds good to me so I can go forward to the TOC and I can say we think this is a good starting point uh we need to fill in some gaps at the bottom there and we've had another volunteer and we'll call it done uh I'll send this to Xing at least Xiang in the next couple of weeks I guess it would be great if we could announce this at KubeCon to say that we actually have a storage sig so I'll unless anyone objects I will see if we can get this voted on by the TOC before uh Barcelona that would be very cool