 Hello, how's it going? We're good. Thank you. How are you? I'm good. Very good. Excited to be here. Well, it's just us at the moment. People joining soon. Yeah. Yeah, totally. And if not, whatever I'll tell you updates about how everything is going. How's the week been? Busy. Oh, nice. This is good. Yes. Good morning or afternoon, everyone. Just waiting for a few more people to join. Thank you. Hi, Quinton. I'll just wait for maybe a minute or two. Morning, Alex. Long time no see and all that. Yes, indeed. Actually see me. Nice. I know, right? I've decided to have different virtual backgrounds based on the call I'm on. That's a good idea. Quinton looks beautiful back there. It's my non-virtual background. Yeah, it looks nice. Oh, where is that place? This is south. San Francisco Bay. So Los Gatos area. No, it doesn't look like Bay Area at all. But I guess I haven't been driving around much lately. Santa Cruz Mountains. Yeah, also from the non-backgrounds. I do actually have backgrounds for Kubecon that are coming out. I sent these out to the ambassadors yesterday. There is a link over in chat to the GitHub that I have tossed the virtual backgrounds into. So you can be all very festive for next week. Nice. Yeah. Sorry, I was having Zoom issues. Oh, good morning. Backgrounds don't work for me because my hair color matches the back of the screen. I've tried everything. We're just like blending. You know, like you're part of the furniture. It's fun, you know. All right. I think, I think we can, I think we're good to start. So, so first off, we have. I hope I'm pronouncing your name right. Who's just asked to have a few minutes to give a quick update on some new community meetups that he's helping organize with a focus on storage on Kubernetes. So I just asked if he, if he could share some of the progress he's making. And if maybe we can figure out if there's anybody on the site who wants to help participate in some of these meetups or provide any content for these meetups. Over to you. Thank you. I appreciate that Alex. Yeah. So basically it's, it's as Alex mentioned, I'm, I'm running meetups that are and forming a bit of a community around data on Kubernetes and trying to just have it be a place where people can share their experiences and learn from each other. And so I, I'm going to share my screen real quick. I mean, I have four slides, so it's not going to be death by PowerPoint by any means. But yeah, I guess I got introed from Alex. And I'm Demetrius. I've been primarily playing in the MLOP space. But Kubernetes was something that was very, very on the top of everyone's mind, especially when you talk about cube flow and, and it was like, Hey, there needs to be something where we can, we can all come together and talk about data when it comes to Kubernetes and potentially evolve, mature the space a little bit. So what we decided on was having this, this meetups on one hand and then the slack, like workspace on the other hand. And from there, you know, I wanted to make it just as open and as inclusive as possible. And I wanted to get people that are doing, you know, are talking about war stories of whatever it is that has to do with data, doing data on Kubernetes or talking about best practices, talking about operators, talking about databases, whatever the, you think is interesting in this field storage. Obviously that's not this without saying I think here today. And it's been really nice. We started about three weeks ago, four weeks ago. We just had our, our fourth meetup and we have them on Tuesdays at nine a.m. And so, so nine a.m. PST, sorry, five p.m. If you're in the UK and I don't know what that is in the far East, but I imagine you, you can do the math. So I, right now I wanted to just present here because I, I imagine there's a wealth of wisdom from everyone that is in this, the SIG and I'm looking for speakers. I'm looking for people who are interested in just getting involved in any way. And if you want to come attend one, see how it is. We, I normally run it either like, like kind of like a podcast interview. So it's a light lift or it can be more of like a talk where you share slides and all that. So it's, it's up to you really. But yeah, like I mentioned, we have this Slack workspace and I can share some of these links in the chat right now in case anyone wants to join and then give their, their two cents. And then the last thing is like, I would really love to see it become something where people can bring their own initiatives, start their own, excuse me, start their own series around whatever it is that you think is, is interesting. Maybe, you know, you say, well, hey, I really want to talk about security or I want to talk about something that is, is top of mind for you. And we can have a series or an initiative around that. So that's it. That's my, my pitch as we could say. And I hope to see, see all you there. If there's any questions, of course, feel free to ask that also. That sounds good. Thanks. I had a question if I may take a second. Um, is the purpose to, to capture user stories or to build APIs around data? I know there's a data protection workgroup in Kubernetes that you may want. I don't know if you'd attend that, but that would possibly have some crossover. Yeah. Oh, that's, that's great to know for sure. I will, I will reach out to them also. But yeah, it's not really. So the interesting thing about this is it's not really working towards anything specific. Like it's not like we're getting together and we are creating projects around working like working groups. We're not doing any open source or anything. It's more just like you were mentioning like, yeah, user stories or best practices, things that you like I have next week, you know, we're having a guy on and he's talking about how he just banged his head against the wall for two months straight, trying to set up a certain pipeline or, or his stack. And, and he wants to tell people the learnings from that whole thing. And so that hopefully they don't repeat the same thing that he went through and don't have to go through that same thing. Well, thank you for sharing. Yeah, no problem. And thanks for letting me on here. Let me talk. I had, I had a quick, first of all, I think this is a fantastic idea. I think there's a huge amount of wealth of kind of untapped information in the space people, as you say, struggling with, you know, these are difficult problems. I think data on cloud computing in general is really hard. And data on Kubernetes is arguably even harder. And, and as you say, people have solved these problems, but the information is not, you know, readily available out there. So we actually had a similar initiative here to kind of canonicalize some of these experiences so that people could reuse them. And I think Luis is on the call, he was kind of spearheading this, we were trying to create a catalog essentially of, of common use cases that we could then document and say, this is a good way of doing this thing. And if you're doing something like this, like here's a kind of a recipe that we know works. And I don't want to paraphrase or put words in your mouth, Luis, maybe you want to talk about that, but it might be interesting to explore the overlap between these, between your meetups and this initiative, because it seems like there's a lot of obstacles there. I think what we had in mind was like a bunch of documents and it sounds like what you have in mind is a bunch of interviews, drug presentations, but but it seems like they might be awaited to still one inch to the other or vice versa. Absolutely. I really like it. And I look forward to attending and probably even participating. I think this is great. And one of the things just like Quinton said, we were looking to do this model where we don't only talk about the, you know, the reference designs of storage, which we have documents about, but also how customers view storage and data and applications and, you know, they get consumed from and, you know, it's one way to be an expert in just how data moves, right, and applications, but another one is how does it get consumed and how does it get used in Kubernetes. And those, there's many questions are still unanswered, you know, for a lot of people and, and this is a great channel for it. Yes. Yes. That's, that's exactly right. Like that whole idea of, Hey, let's get together. Let's share this knowledge because it's untapped and we need to be talking about it or writing it. I mean, I did have the idea of after the meetups taking what I'm doing is I'm taking some of these gems that people talk about and I'm writing them down and putting them on to medium. And so I'll connect with you offline, Luis, to see about maybe there's some crossover that we can do for docs that you potentially already have. But I love the idea of, Hey, this is something that people do over and over. Here's the best practice for it. That is, that's awesome. Yes, that's right. I was going to tap us, you know, people in the community and also participate too. That'll be great. So yeah, I would love that. So I'll, I'll connect with you offline because I'm definitely looking for speakers. I'm looking for people to share their wisdom and share, share their knowledge. It's every week. So on Tuesdays, every week, I would like to start doing. So these are live meetups that I do on Tuesdays. But as it grows, what I'd like to start doing is also creating like a podcast that's not live. So it's not like contingent on trying to get a lot of people there and, you know, a lot of publicity. It's just like, Hey, we have this following already. So people listen to us. They subscribe to us on YouTube or podcast land. And we put out different series of podcasts. One other quick question. So it seems like there's a lot of overlap between what that group does and what this group does. And I don't view that as a bad thing at all. I think, you know, historically, this group has focused a lot on the actual infrastructure at the, you know, layers of the storage stack and, and all the various open source projects. And we tried to get this sort of use cases analysis and publication going. And I think it's, it's sort of been tricky. I'll put it that way. But I would love to see an ongoing collaboration between the meetups and the SIG. You know, one model that comes to mind is maybe you kind of give, come and give us a 10, 15 minutes sort of summary per month or something like that. It says, here's the really cool stuff we did this month. Here's, you know, stuff you should probably go and check out. Here's a podcast. Here's this, that's the next thing. I think that would be super useful to this group. And then I don't know how, you know, maybe the reverse might also make sense. Maybe somebody from the SIG does a, you know, whatever quarterly presentation to your meetups, just to kind of keep the two groups in sync. It doesn't sound like they need to merge into one, but, but they do probably need to kind of know what each other's doing on a regular cadence. Totally. I would love that. I would definitely, I welcome that. I think that's, that's an awesome idea too. So that we're all in the loop. That makes a lot of sense. All right. Thanks. Thanks to Demetrius. And I'm sure we'll have lots of interaction both ways coming up. Very cool. Thank you all. So, so everyone, I just wanted to do a quick sync up on where we are on the performance white paper that we've been working on. So I wanted to, I'll just share my screen just so that we can go through it briefly. Can you see this? Okay. Yes. Cool. All right. So, so what I've done is I've simplified some of the parts because we, we have, we do have a lot of content in the doc now, but I wanted to, to make sure that the, we're not, you know, I mentioned this at the last TOC meeting. I wanted to, to make sure we, we didn't make perfect the enemy of good, so to speak, right? Because I didn't want to, to continually delay the document until we have perfection. So I've simplified the document and I've made the bits which are, which are currently complete, a bit more scoped out. And I think we may be ready to, to put this out for, for review. So, so I'm just going to quickly scroll through this to, to see if we've, we're okay with this before we, before we do a release. So the, the basis of the document is, is to, is to provide some background on how end users can understand the performance and, and, and potentially do benchmarking. But also, you know, highlights the pitfalls and some of the challenges with, with doing this so that they can understand more clearly how to do apples for apples comparisons in these environments. So I've started off with a simple introduction that basically says always test your own application and your own environment. Don't rely on published results from vendors. And also I put in a link to the white paper so that people can understand, you know, the general attributes and terminologies of, of the, of the storage environment before they, before they start reading some of these. I talk about the two different classes. So, so volumes and, and databases and we have quite a, quite a detailed description of what, what, what forms say a database workload and the volume workloads, which, which covers, you know, some of the general principles and some of the things to look at. We have a particularly well written section that covers the common pitfalls and considerations. So for example, what tools to use to, to measure what, what metrics and what type of, you know, basic terminologies to, to, to be aware of things like, you know, when you're looking at latency, don't just look at the, the measurements at a particular point in time, but look at the measurement over time so that you can kind of sort of see the different percentile numbers, the impact of concurrency to performance, the, the, the impact of caching and, and for example, compression, compression, things that might affect the performance testing when it comes to, you know, the, the, the environment that you're testing in, you know, aspects that affect the environment in physical infrastructure as well as in, in cloud environments, things like the effects of random rights and rights amplification, the effects of encryption on benchmarking, the effects of the topology, and notes to talk about the, the challenges of the, on the client side of testing the performance because, because, you know, very often the clients can be, can be the bottleneck in these environments, things like, you know, the performance implications of, you know, say, HA and replication and perhaps data protection. And also, you know, some of the things to keep in mind in terms of, say, things that happen in the background in, in, in storage systems. So, you know, some storage systems might have outs of bands, compression or garbage collection or something like that, that, that, that can affect performance. And then a little bit about benchmarking tools. So, you know, a note about level setting the environment to make sure that, you know, your, your things like CPU and network in the environment are comparable. And then finally, we were supposed to have some section on actual, on how to actually perform evolving benchmark in the database benchmark. And this is kind of where we're currently on a little bit stuck. So we don't have, we don't have, we don't have a good information on how to run the benchmarks. But at this stage, I am kind of thinking that rather than hold the document for any longer, there's still value to publish the document with, with this information as is with some basic, very basic pointers to, to the benchmarks that, that people can run. And then we can iterate and maybe provide the version to, when we're ready to, to actually, you know, specify more details on how exactly to run those benchmarks or more examples on how exactly to run those benchmarks. Because I think understanding the performance and some of the terminology and some of the concepts and some of the issues that you come across is still important and there's still value there. Does anybody have any thoughts on this? Do we, do we think we should move ahead in that fashion? So I have, so in Vitas we actually, so CNCF got this deal from packet.net, which is what they call it, bare metal in the cloud. Right. It will mean something. So basically you get bare metal instances, but they are in the cloud. So we, what we are doing with that in the test is we have started running nightly benchmarks because community has been asking, like, how do we like, how do you make sure that you don't introduce performance situations and stuff like that. So we just started doing that just like a few days ago. We just got the environment up and running. So we run a, we have a very basic suspension stuff that we, that runs every night and then reports on a Slack channel. How many, what was the QPS, what was the latency and that kind of stuff. I don't know if it is completely related, but this is just like a very basic startup kind of thing. We hope to build more features around it and stuff, but I don't know if that can be used as an example for how to set up a benchmark and run it. But this one is obviously very test specific, but, and this is more driven by the fact that the community has been asking for it, not necessarily. So it's very end user oriented from that perspective. I mean, you know, again, that sounds great, but I guess the challenge I have right now is, you know, how long do we kind of delay putting the documents out to wait for somebody to write some of this in a way that end users can actually consume. Because I think we might sort of be getting trapped in the sort of idea generation where there are lots of possible options for putting content into the documents, but I want to try and balance that with time. I guess that's kind of what I was feeling, because now just as I was talking about what we did with the test, I realized that 90% of it is specific to the test itself. There is not much to learn from for somebody who wants to run against a different system. I would suggest, I think the first part of the document up until the tools section right at the end is looks fantastic, to be honest. I don't think you need to, you might be kind of focusing on what's missing and what took so long, but I mean the document that you went through looks fantastic, and I would punish it as is. I would actually make the following suggestion to remove the last two sections because they're incomplete. Add a section of links to other information. The test benchmarking wiki page or whatever it is can be one of those links. The others can be some of those tools and have a very explicit comment at the end in the conclusion that volume two will cover specific benchmarking tools and how to best use them or something like that. And one sentence. And then people know that there's a volume two coming and then hopefully we can actually kind of set a timeline and have a target date for that by whatever it is. It doesn't sound like a huge job, but having said that, it's a year in the making and I guess it's proven tough. So maybe it's more difficult than it sounds, but yeah, it would be nice not to kind of wait another year for that, hopefully. And maybe someone on it who has experience. Just to add, the two things that the community has been asking for, it may push the document slightly out of the scope. One is chaos testing. I don't know how the software withstands instances going down. That is something that they've asked for. The other stuff they've asked for, they've asked for as a problem in with this, but I think it applies to all database instances, which is version compatibility. I mean, these go into functional areas, but these are like things that people are really, really concerned about when basically adopting a software project. Yeah, that's a really good point. So following on from the original landscape white paper, we had covered the different storage attributes. So performance was obviously one of them, but I think availability was another one of the key priorities. So we could say that this performance document sort of covers off the performance attributes in a little bit more detail, and then we can start working on perhaps a document to cover things like availability and failovers and data protection and those kind of things perhaps. And chaos testing could ultimately be part of that in terms of the tools or whatever else that or methodologies or whatever that you could use for that. If that makes sense. Yeah, sorry, I'm just throwing things out there based on the data I'm collecting. It's not necessarily structured, but this is, yeah. I think those are very, very important topics and I think we should cover them. I agree with Alex. They're not necessarily performance, but definitely one approach would be to dive into each of those four or five areas that we've mentioned Alex and dive into as much detail as you have a performance here. The one comment on that is that there's kind of an inevitable overlap between these areas. So, you know, if you have something that doesn't have redundancy, it tends to perform better. And if you have something that doesn't handle failures, then it also tends to perform better and vice versa. So one would have to just think carefully how one ties them all together. I think one can fairly easily deal with them all in isolation. I think it's where the overlaps happen that it becomes complicated. And I'm not entirely sure how to deal with that, but maybe have some ideas. Yeah, in the performance document, we specifically sort of highlight that, you know, things like the way your data is protected and your availability and consistency, for example, are all big factors in how your performance attributes work. So we kind of point out those things. And I think that's actually that sort of overlap is covered quite well in the original landscape documents. But yes, you're right. I want to try and avoid having sort of lots of circular references if you see what I mean. Yeah, that's a good point. I think that the original document did deal with it well. And maybe we just dive into each area relatively in isolation and just refer back to the document and remind people that these things all influence each other. But this particular document is squarely about performance or durability or reliability or whatever it happens to be. Sounds like a great idea. Makes sense. All right then. So I'll send the link out. I'll send the link out to the to the mailing list and hopefully we can we can we can get some movement on that. Okay. Alex, I think you've done a great job pulling it together. Well done. Thank you. Yeah, I agree. Thanks, Nick. And thank you for your input as well. All right then. So we have we have one other a couple more items. I just wanted to bring up so the the TIKV project. We had completed the due diligence in this and it was going through the TOC votes. And we realized that there was a potentially. Well, not potentially there was a core repo that wasn't covered by the initial due diligence. So the decision was taken between the TOC and the project to to work on including that additional repo into the due diligence PR and then to kick and then to restart the voting process. So that's, I'm just I'm just sort of highlighting this because we had a few discussions offline during this week. Erin, was there anything else worth capturing from that? Oh, which core repo was it? Was it like level DB or something? No. So TIKV had has a dependency on something called a placement driver. The repo is called PD. And that repo is also used by TIDB, which is obviously, you know, a separate project. And so it hadn't been kind of bundled into the into the original TIKV due diligence. So the project team have sort of said, look, in order to kind of remove any of these concerns, they'll bundle the placement driver repo into TIKV and under the same sort of governance structure. So that it's just part of the part of the same thing from an IP policy point of view. It will kind of, yeah, when we did all the presentations and when we did all the reviews, it was just assumed that PD was actually part of the submission. And, you know, honestly, it was, but we just needed to, I guess, formalize that. So hopefully it's not a big deal. The other item I wanted to quickly discuss and, you know, hopefully this doesn't take too much time. Derek Moore has, who had previously presented the Pravega project, is looking to move forward with the due diligence to proceed with an incubation submission. So just as a sort of mental refresher, Pravega is a project which is currently sponsored by Dell. They have, it's a streaming storage product. It has some similarities to Kafka, for example, and it also has some sort of message bus similarities to NATS. If you haven't read the incubation proposal, it's worth reading that because there's actually quite a lot of useful detail in there. We all thought it was a great project and, you know, the presentation went particularly well and we've recommended to move forward to the DD stage with the TOC. I'm waiting for one of the TOC members to step forward to work with us on doing the DD, but I guess we also need to figure out who's going to work on the DD from our end. So I'm happy to help out myself, but I'm quite time limited over the next couple of weeks. So I was wondering if there are some of the else who could help out with the due diligence process as well. For what it's worth, the proposal, I had been working with Derek on the proposal and iterated a few times. So the proposal is actually very strong and already covers things like end users and use cases and things like that. So the due diligence process should be fairly straightforward and we just need to sort of double check that the proposal sort of matches what's live in the project today. Just to clarify something, Alex, so this is a sandbox proposal, right? No, it's an incubation proposal. My apologies, I got it wrong. The due diligence is very lightweight or too non-existent, but incubation is a pretty heavyware process. Yeah, exactly. You know, like I said, a lot of the criteria for incubation were already covered in a fair amount of detail in the proposal. So I don't think there's a lot of work to sort of document or dig into the detail required, but you know, we have to make sure that we've covered all of the areas based on the guidelines document. Yeah, I also unfortunately won't have enough time in the coming month or two. Yeah, if, I don't know, maybe, you know, Luis or Shing or Sugu, you might be interested in helping out so we can maybe try and make a go of it over the next couple of weeks. Yeah, maybe I guess another one of our things. When do you need this? Well, there isn't obviously a specific deadline per se, but the proposal has been in now for a few weeks and it would be good to sort of get the timeline when we can start working on it. I imagine a few months, you know, if it was done in October, I would imagine that might be sufficient. I don't know if there are any deadlines before that for cube cons or anything else, but Yeah, so maybe maybe if we can, if we can commit to start working on this in September sometime or the beginning of October. I was just, we might want to kind of finish it in October. So that might require studying it earlier. Yeah, all right, I agree. Let's, let's, let's, all right, let's commit to working on it in September. I should have more time as a backfill in September. But again, you know, if anybody else is available to help at that point, that would be useful too. Sorry, I just want to clarify with you implying that you might be available. I think you'd be a fantastic candidate. I just, I want to know the time that I can, you know, see if I'm available. That's why I was asking. Okay, yeah, I mean, we can probably work around, you know, within reasonable limits. But if you told us you could have it done, you know, at the end of October, I think that would be good. Because if you could have it done in the second week of November, I think that would be better than not having it done at all for sure. Yeah, okay, yeah, I can, I can take a look. Awesome. Thanks so much. That was the last thing I had on the on the agenda for this meeting today. So, unless, unless anybody had any other things they want to raise, we get 15 minutes back. Thank you. Have a great day. Alex. Sorry. Oh, hi. Hi. Can I put open ebs presentation for the next week's agenda. Just wanted to give a heads up that also gave a proposal for moving towards integration. Yes, sorry. That's a very good point. I'm, I'm, I'm sorry, I didn't mean to mention this. So, about a week ago, I believe, open EBS project. That is currently a sandbox project has put in a proposal to to move forward to incubation. We're, we're currently looking to put to put an open EBS presentation on the agenda for for the next meeting on August the 26th. Cool. All right. Thanks everyone. Hi Alex. Oh, hi. So, yeah, I just want one quick question. So we submit it as well like two, two, three weeks ago in the form for the sandbox projects. I'm just wondering what is the next steps the process just what's happening next. Right. So, if you've this is for the for the idea. Yeah, the data lifecycle project. Yes. So, if, if you're making a sandbox submission, then the, the TOC have a new process where they were they vote on sandbox once every month, I believe. The best person to the best person to speak to is is Amy Perrin of at the CNCF. But you should also be able to look at the, the current status in the GitHub repo for for sandbox. So there is a, let me, let me in fact let me just quickly look that up now. I don't see the current actually. So, this is the, this is the current board. I don't see it on there. I'll double check with Amy, but effectively. Yeah, I wanted to confirm that I did everything correctly. All right. I'll quickly double check that but but it should just be a simple a simple vote at the next tier sequel. Okay. All right. Thanks everybody have have a good rest of your day.