 to. It's five minutes in, so we may as well start. If you want to present the document on the screen. Yeah. And Alex, I'm just looking at the attendees right now, because I know about, you know, half the call was involved in the paper and the other half wasn't. I know they quit and asked earlier if folks are taking a look at it. Maybe we can probably start it out that way again, because I think it's Saad and T. Nelson, sorry. What's your first name? Oh, I'm you. Tony Nelson. Hey Tony. You're seeing again. Yeah, and John Griffith. I don't know. Have you guys had a chance to look at that, the white paper? I took a brief look at it yesterday. I haven't really dived into it. Just kind of glanced over it. Okay, so an overview from Alex to be useful there. Yes. Okay, cool. Okay, so I'll quickly do a quick skim through. So what we wanted to do with this document is give the audience an understanding of the storage landscape in terms of both the terminology that's used in this space and some idea of the different types of solutions. And more importantly, what we're trying to do here is trying to give people an understanding of the different attributes of the storage system such that they can better pair the application requirements to what different storage systems can actually provide in terms of attributes like availability, scalability, consistency, performance, that sort of thing. And we tried as much as possible to keep this fairly agnostic and, you know, not product specific in any way. And we've minimized the, you know, that we only use products where product terms when they are, you know, kind of like obvious S3 logic stores and things like that. But otherwise, we've tried to keep this as a way of getting an understanding of the storage environment. And the way we've done this just as a general layout is we define the attributes of the storage system. We define the layers that are formed within that take part of a storage service, you know, whether it's the way data is protected or different virtualizations or distribution topologies and that kind of thing. And then we dive into the different data taxes interfaces covering two main areas. The first one being volume where we look at block file system and shared file system. And secondly, what we're calling an application API where an application talks to storage system over an API settings like object stores, key value stores and databases, for example. And then we have further sections where a reader can get additional information on, you know, block storage, file system, object storage and key value stores specifically. We decided to defer databases in general to a later version of the document primarily because databases was a really large scope and, you know, could even be a it might even merit a document of its own. And also partly just from a pragmatic point of view, from a timing point of view, it was a bit of a pie that was too big to bite off just now. So very quickly, we talk about the attributes. So we have a section here on the attributes where we talk about things like availability, scalability, performance, consistency, durability. And we put in a small section here about instantiation and how you deploy them. We talk about the layers. There are a couple of small sections in the layers which need to be fleshed out but they're identified in the comments. We cover things like the topology of the storage system and the data protection capability. And we talk about data services like replication and snapshots and encryption, for example. And then we have a section on the data access interface. So talking about, you know, how workloads actually interface with the with the storage system and how they actually consume storage out of the storage system. And we cover, you know, block file system, share file system, and also object stores, key value stores. As we said, databases were deferred. We are building out a comparison table and I'm trying to do some work to make this to a pretty diagram rather than just a table. Probably do that in the next couple of days. And then we have some further detail on each of the store types. So we have a section on block stores, another one on file systems, another one on object stores, and another one on key value stores. We then also talk about how the storage is orchestrated. So talking about the different control plane interfaces between the container orchestrators and the control plane of the of the storage system. And we discuss and list some of the interfaces there like the native drivers and the topography of plug-in influx volume and obviously CSI. And we also try to put in some, we also try to cover orchestration interfaces for the API components. So, you know, how do you orchestrate an object store or database or key value store, for example, and obviously, you know, the volume orchestration is probably more mature at this stage. So that has more detail than the API section. And then finally, we have the appendix, which has a little blurb around some of the history for the documents, mostly for just information purposes. And we talk about, we have coverage around things like consensus protocols and consistency, which are fairly complex concepts, which are, again, poorly understood, but often referred to inconsistently in different representations. So this kind of gives a nice, a nice rounded summary of some of those concepts there. Questions? Do you like it? Do you hate it? Like it. Good work. Yeah, obviously, I'm somewhat biased because I was kind of involved in this, but I must say I read through, you know, it took a long time to piece all the bits together and there were multiple authors and a lot of documentary structuring at the last minute. But reading the final draft, I must say it really comes across as super valuable to me. I think I hope it will be very well received. I think it gives a very good balanced view of everything from a factual point of view. I want to congratulate everyone who was involved, because I think the end result is very impressive indeed. I had one question, actually, that only occurred to me after I read the final draft, which is one thing we don't talk about, and it is obviously a bit of a contentious one, so maybe we want to avoid it, but I think cost and pricing is a pretty salient property of storage that people take into account when they choose what to use. And I wonder, I don't think we talk about it much. We have that section at the beginning about what did we call it provisioning and something. But I think there's maybe a bit more to say around storage services like S3 are typically priced with this sort of structure per gigabyte or per IOP or whatever it happens to be, whereas storage devices like storage servers and whatever are priced typically this other way, and that may play into which of the two you choose, in addition to performance and all the other things. And some of them are more capex focused, and others are more opex focused. Pay as you use versus pay for a big box and use it anywhere you like. Are there any thoughts on whether we should talk about that at all, and is it something we can talk about sensibly, or is it just too diverse to be able to summarize? I think adding a little bit to the deployment options section where we say we possess the differences between hardware, software and cloud services, for example. I think it's where it's pointing at cost as a factor there, because hardware typically inclines capex on the other end of the spectrum cloud services typically provides, typically implies subscription. However, it is one of those topics where there are vast ranges of exceptions in all of those things. So as you were talking, I was kind of thinking, could we put relative costs of different systems in there, but then actually we could have an object store crossing more than a block store, depending on how those things are configured. I was kind of thinking about that the same way too. Maybe you can generalize it, and you can say most expensive is structured data storage for databases, mediums, block store, and cheapest is object or something like that. But when anyone picks that apart, it's not always true. So I think it's tough to really get on those details. And then the other thing I was thinking about is what's the audience? If this is a technical paper, if you start going down that path, I think to be clear and to be consistent, you have to get into some kind of details there, and is that just going to add extra to this paper, confuse the audience, or just not be aligned with what our actual audience is? Yeah, those are definitely valid points. Just to be clear, I wasn't necessarily suggesting that we say block stores are cheaper than file systems or anything like that. But more is probably more to do with the software-based stuff built on off-the-shelf hardware, has certain pricing properties that are different than proprietary hand-made enterprise storage systems. Now, I know this is going to get controversial, and maybe I don't have the pricing details at least off the top of my head right here, but it might be worth saying they're either comparable in price or different in price or whatever. Although it's not a technical decision, I think it sort of inevitably plays into decisions even technical people make. Developers are going to choose, in some cases, choose something that have easier access to like an open source software-based solution that they can download and try out and use in their small product versus having to justify large capital expenses. I personally don't think this is the right forum for that sort of a sales pitch. I think it'd be really valuable to call out the different options, but it doesn't seem like trying to associate a cost of each one is really something that you can actually do. I don't think it's necessarily overly useful because you don't know what existing hardware folks have. You don't know what kind of contracts they have with vendors, all that sort of thing. You don't know maybe they don't have a team of developers to work on open source. I've written and given talks on that topic, and you can write a whole other paper on that topic. John's playing like the devil's advocate here for sure, and he's a background from NetApp, a background from EMC on my side, and I agree like from from EMC's perspective, or even I think Dental just want to can't speak for Delta, I don't work for them at this point, but I think that an open source solution, you added up with the hardware and the people it takes to actually run it because you're not getting it supported by an enterprise company, like the cost and the being similar. The cost savings is very much a subjective thing that just like John said, you can write a paper about what that translates to an organization depending on your structure. So how about this? I kind of agree with all of those comments there, and I think that trying to compare ranges or pluses and minuses or pros and cons is probably not suitable for the documents. However, on the other hand, I think it's worth pointing out to a developer who's looking to compare costs and just maybe some basic things like the differences between purchasing stuff up front versus purchasing services and subscriptions with the cloud is one obvious one. And then I think it's probably also worth pointing out to people that products are generally priced according to the attributes that they support. So for example, if a product is focused on a capacity attribute, like an object store, it's going to be priced in terms of dollar per gigabyte. But often both things that you purchase or services that you utilize can be priced in terms of dollars per IOPS or dollars per megabytes per second by dollars per performance. And we should probably also just mention that people need to factor in dollars per availability because often the number of copies or the number of replicas or the number of the amount of redundancy tends to increase cost and just leave high level in that respect so that people can say, okay, if we're looking at things, these are the sort of accesses that affects the cost without actually telling them what the costs are, what the ranges are. And I like that. I think generalizing at that level will be useful if the audience is the developer and it's going to be more information. I think that makes sense. And the comment you have before, how can we break it up? We could say there's a traditional mode of the capex purchases. You buy everything out front. You run it yourself. You get it supported. There's the other model, which is the service-based model. And that's different correct reasons. And then maybe you can even see something in the future for the next white paper, which is, I mean, there's a leveraging cloud-aid attack to run some of these services. And maybe that's a better place to be, who knows. But maybe there's three models that we talk about there. Yeah, I like what you said, Alex, as well. And I think not mentioning cost as a consideration when comparing storage alternatives is not the right thing to do. So yeah, just adding that is a factor. And these are the kinds of things you probably want to think about capex versus uphooks per gigabyte versus per IOP, etc. Now, just in terms of logistics and timing, so there are a couple of sections that don't mean to be filled in. We have people nominated for them. But of course, we're also going to have to take on board any feedback that's presented. We were tentatively looking to present, I believe next, is it next Tuesday? At the talk? To the TOC. I actually dropped the TOC an email yesterday to ask them if they want us to present this stuff, or if they just want to read the document. And I haven't looked at my inbox yet, but I'm not aware of any replies to that yet. I think let's give it a while. There's certainly no urgency to talk about it there. People have not been haunting me. So let's see what they think. I think what we do need to do is talk about it at the KubeCon China event in three weeks time, I guess it is. So as long as by the time we stand up there, there are no violent objections to our documents. So I think we're good for that. And I have, as I said, the document to the TOC. They can read it if they want to. They can reply to my email if they want us to present it to them in a summarized form. So let's just give it a few days. I think what I would like to do is make sure that at least some significant number of people outside of the authors of this paper show visible evidence of actually having read it and provided some feedback. So John, thanks for yours here. And if we can get more, I think that would be great. I wouldn't want to feel like this document was purely the opinion of the five authors and not an opinion shared by anyone else. That would be bad. Yeah. How to really do that? How to be encouraged people to read the document? Personally, I would give it another few days for people to see your email that you sent out. And we've got this forum. I've announced that we have a TOC meeting next Tuesday, Wednesday, I believe, Monday, maybe. So I can verbally tell everyone on that call. So I didn't want to open it up to two broad feedback just yet until we had let the working group look at it and comment, just because you can become, or we can all become inundated with too much feedback and not be able to process it. But if by next week we are not overwhelmed with feedback from the working group itself, then I can announce it at the TOC meeting, which just to be clear includes TOC members, but also typically around 50 to 100 other people. And so I think that'll be an effective way of getting more reviewers if we want more. Okay. Sounds good. And then hopefully again, KubeCon will add yet more interested parties around the agenda and people will probably sign up to come to that. So come three to four weeks time, I'm guessing we'll have more than enough feedback. And then we can, as I think the plan was to sort of declare it published and final by KubeCon Seattle, which is about a month after KubeCon Seattle. So I think that sounds reasonable. Does anyone have any ideas? That sounds good to me. So I guess apart from you know, finishing off the TOC and pressing comments and we probably need to create a draft slide deck by next week, right? If you're taking that to KubeCon China the week after. Well, I think the conference is on the 13th of November, if I remember correctly. Okay. So yeah, I mean within a week, I think the slides are probably supposed to be uploaded already. And we can put a wireframe slide upload there. I don't think they get made public. I think they're just trying to encourage people to make sure they have actually prepared their slides, their presentations more than the night before. But we can certainly amend the slides up until not long before the 13th. Yeah, let's maybe have a draft in the next week if that works. Okay. I think we've got most of or some of that anyway. So yeah, the slide deck, then I think we're good. All right. So I had that first copy of the slide deck from a meantime done. So I can, if somebody could point me at a CNCF sort of template, I'll put the content into that and then we can iterate on that. Sure. I think I stand corrected, but I think I sent you that a couple of weeks ago, but I can dig it out again. I don't think there is actually a template, but there is a CNCF GitHub repo that's got all the logos and it's got some examples slide decks and stuff like that. I think that's as close as we get the actual coupon template. Do they usually send out those templates for the previous coupons? I haven't received any yet. I had a look around. I can't remember if it was for this group or for a different group, but I couldn't find any in my emails or on the website. So we have a deck that we had, we have a deck that we had that are prepared for the storage working group and for the coupon EU earlier this year. Should we just reuse that deck as a template? I'd be fine with that. I don't think they're very strict about the slides being consistent. The slide decks for the different presenters being consistent with each other in terms of all right. I will only use that then. Yeah, I've got all the time data. I'll just send a link in the chat. But thank you so much for your efforts here. Thank you everybody for it. Thank you everybody actually for it. It was a team effort, so we did really good work here. And I think this will make it easier for everybody to understand storage going forward. So if there's anything else, is there anything else? So we do have two talks, right? So the slides that you are preparing, that's for the deep dive, right? For the intro, do we need any, maybe just a few slides? We can actually talk about what this group is about and what we're going to do with the white paper. So do we need a few slides just to cover that? Or is just to talk? Yeah, you're probably right. I think we need an intro talk to just kind of cover some of the basic things about the working group and sort of a high level we're working on the document and this is what it covers. And then the deep dives can be sort of actual, maybe actual sections or we can discuss some of the sections of the document in a bit more detail perhaps. So for the intro, maybe we can use some of this slide that you were just sharing. Yeah, and this one and see if we can use some of this. Yeah, that's what I was thinking too. Okay. One thing I've learned from the Kubecons is that the audience every year, the actual people attending is growing so fast that the percentage of people who've never been to a Kubecon before is pretty high. And this one being the first one in China is going to be even more so than usual. So yeah, don't be too shy to present material that is quite similar to what's happened in the past just because one, the repetition is kind of useful because people forget this stuff. And two, the audience is going to be, I would guess 90% people who've never been to a Kubecon before. So yeah, reusing what you've got is not a terrible idea. All right, makes sense. Clint, I only really got involved in this group in the last few months. And I don't have full visibility into what other things this group has done before I joined. So we might, you know, we've been kind of heads down, getting this document published recently, but we may want to reincorporate some of the other things that this group was doing before we dived into the doc. I know you had some presentations from various technology groups and vendors and whatever. I don't know how well received that was, if it was useful use of time, if we want to get that going again. And if there are any projects that we, you know, if we identify, you know, holes in the landscape that we think we want to tackle, I don't know if those kind of discussions have happened before or with scoping. Do we actually have like a charter for this working group? This is what we do and this is what we don't do? I think that's how we initially, like when you joined, that was one of the things we wanted to get from the TOC was to define like what they were looking for from us. And I think the most tangible thing was to start working on a white paper. So, I mean, we've, like when we look at that deck that was posted by Alex, we do have like on their slide number six, which is what we kind of interpreted as our mandate. And the three things were to clarify terminology and landscape, to look at how the components are used in clouds and to compare and contrast properties of storage, such as availability, durability performance, etc. And I think that kind of covers like building the white paper. But I'm definitely all ears to hear from folks, you know, what, what they would see is an easy time in this working group moving forward, whether it's here, whether, you know, presenters, etc. So, just, just for context, one of the, one of the things so I think there was a lot of debate at the tail end of last year. And one of the things I recall on one of the talk meetings was that there was kind of a general consensus that working groups shouldn't exist for the sake of existing, but they exist because they're tasked to do things by the TOC. You know, whether that's, for example, reviewing a project or writing content, or, you know, whatever that thing might be. So I think we probably have an agenda item as this sort of document now comes to a close as to what we do next. That's kind of where you can be. Yeah, I think, I think there's a sort of a bi-directional aspect to this. So I think on the one hand, the TOC wants to know what's going on in the storage world and find out where the problems are and find out, you know, all that kind of stuff. And when I said the TOC, I think I'm making up requirements of the TOC. I'm not aware of anyone having, anyone else having said we want the storage working group to do this. I believe this working group was kind of spawned of its own accord. So I'm not sure that the TOC actually requested that a storage working group be put together and answer the question XYZ. It's more that it self-formed and then the TOC was saying, well, what is this working group actually doing? What is their scope? What are they planning to do? And that's where the conversation started. So I think we can propose what we want to do and what we want to provide to the TOC and to the CNCF in general. And as long as the CNCF does not object to that, I think we're good. Off the top of my head, the things that I would imagine that would be very well received are, so this document is a good starting point. The other thing that I believe that people are very interested in and which we didn't actually cover very well in this document in any detail is how are these things actually used? So one thing we could do is publish case studies of some of the details of how particular use cases exist. We could get guessed. I'm just thinking of someone like GitLab just to take something off the top of my head. So how does GitLab do their storage behind the scenes? And what are the problems they've had? And I know they just migrated from one place to another place for reasons. I would imagine that people would be very interested in understanding how GitLab does their storage, why they do it that way, what they did in the past. Now that could be somewhat contentious. Clearly, you would not want a big user to stand up and say, we hate Cloud Provider X. We love Cloud Provider Y. But I think there's a genuine interest in understanding how some of these things are actually done behind the scenes. And some companies will be prepared to talk about that. I would imagine Netflix is another example, which is a big, high-profile thing where people must wonder, like, how the hell do they store all these movies and metadata? And are they prepared to tell us about their journey there? So that seems like an interesting area we could explore either with presentations or with documents or whatever. I'm wondering if, I think we've got a good outcome of the working group for creating this document. And Quintin had to rewind, like, the TSC did ask to form it. And that's when Ben kind of stepped up and said, okay, I'll lead it for the TSC report pack. So I do believe it was like but I think the tangible outcome of it has been one, like bringing folks together. At one point we had 30 people or so that were joining the call continuously. I think that was when we were doing a lot of our presentations or even maybe one of the white people was first discussed because people were really interested in what was going on. And then we had the white paper and I think we've had a little bit of a tailing off of attendance at this point. But my thoughts are kind of like in terms of timing and where we're at like within the conference season in the year, like this seems like a great outcome of the working group. And it's something that I'm kind of interested to see like how it goes. Like what's the feedback from it that does the CNCF and TSC find this really useful, that was a good use for our time. And maybe it's then considering we have cube cons coming up, etc. Maybe it's like we take a little bit of a break on the working group. And then next year we address our like what's the next thing that TSC actually wants considering what the feedback was from the paper and like and how we how we what was presented. Yeah, that sounds like a perfectly reasonable approach. So I'll tell the TSC we're basically calling this task done. And based on the based on the feedback to the document, we will decide whether we want to reconstitute in the new year for the next step. And then I would propose that in the next step, we come forward and say these based on the feedback we've received, we think this these three things would be the next logical steps for this working group. And we're essentially reforming to do item number one on that group list or maybe two or three in parallel. I'm not sure that depends how it works out. I think that's totally reasonable. I think that the TSC would welcome proposals from us as to what we think we should do. And you know, rather than us saying, what do you want us to do? Because I think we're less likely to get useful feedback from that right instructions. Yeah, no, I mean, that makes sense. I think getting feedback from I'm kind of hopeful that there will be some of your takeaways once people have enough people have reviewed the document to talk to this about who we've talked to practice in QBCon. And one thing that might actually be really useful is to actually you know, poll the audience when we do these sessions of QBCon as to what I don't know if we're going to be given up. I don't know if we're going to be ready enough to give them a couple of options, but maybe ask them what they want to see next, what they see their pain points are, what their decision points or issues, you know, they might say, actually, well, this is all great. But what we really want is a roadmap on CSI next, for example, or something. I don't know, I'm just making stuff up. Like when CSI and the CNCF or like something like that. I think that's the there's definitely things that are going to happen in the next six months that are going to change the storage landscape and maybe there's other opportunities to come up. Yeah. So so maybe we maybe we ask and see and see what comes back. But I'm hoping that there will be a few things that might be, you know, immediate follow up directly from this document. So somebody might say, well, okay, this is great. But actually, I don't think you captured this area. Have a separate document or we might have a separate discussion or some other project presentations or whatever related to that, for example. Hey, I had a quick question. So if I share this document with folks say in my company, how would what's the best way for them to provide feedback for it? Probably directly on the document, I think. Okay, gotcha. I just want to make sure that there's some what the recommended way is what I give them. So if it's just directly on the document, I'll tell them that. Yeah. This forum would be an alternative. So so they're welcome to come to this meeting and and provide. I mean, first prize is written comments in the document. But sometimes comments are more usefully presented verbally to people saying, look, I read the thing. I didn't quite know where to put this, but my feeling is XYZ. And that's also fine. Okay, cool. Thank you very much. And maybe we should make that known like in terms of the I don't know if you said that in your email, Alex, but I think we've got three of these sessions leading up to QCon. And if you have the comments to come to these sessions to verbalize them, I totally agree. I think that that's probably a better forum for some discussion. Yeah. Okay. I can have a follow up email next week. I think it was fairly clear in the one you sent, but never heard from the following. So just to briefly circle back and then I think we're done. So yeah, I think that QCon Shanghai and QCon Seattle solicit audience input as to what. So first of all, make them aware of the document and tell them this is basically certainly by Seattle, this is kind of delivered. And then solicit feedback on whether and if and what sort of next steps they would like the working group to take and have in the wings a set of proposals just, I mean, rather than we end up with a room full of goldfish, not able to, we can without preempting the input we might get, we can at least have in the wings a set of potential proposals to get people thinking. Yeah. Okay. Cool. Okay. Thanks all. Yeah. Thank you all. See ya. Bye.