 Okay, so I think we're making good progress, fleshing out my sections, so that a few hours more work to do to get them in a decent format, but hopefully later on today I'll get most of that done. And we have Xing has volunteered to help with data with the key value access stores, but I haven't had any interaction with him specifically. Do we need to invite him to this crawl or to the status update call maybe next week? Yeah, I assume that would have been the case. Yeah, he's volunteered to write those sections. He added comments to the doc, and yeah, he should definitely be added to all invitations and emails related to this. All right, I'm really sorry, I just updated the table of contents and it's wiped out the comments we had to put in about who's doing which sections. I think I remember them all, but Clint, do you want to give a quick update on the blockstores in the file systems that you were looking at? Yep, I will. I just started working on the block this morning, and my plan was to flush it out this week. I think I'm starting with the tables because I feel like filling in the tables will help me fill out what's the right type of more detailed information to put in the descriptions. I went through the first pass on the block table this morning and then I was going to do the file system table this afternoon. Is there time for me to ask feedback on one quick thing in the block table to see what people think? Sure. Yeah, I guess I'm curious on how we think that this should hold up against what type of, possibly against what type of technology, and this is where it always gets more subjective, but as we create this table, I'd look at one box. If we look at the local and then the performance box, I put in that box that it's limited by local components and it can benefit low latency applications. I think that the obvious statement is it's limited by local components, but it sounds negative in the way that that's said, but in reality it can be the right thing. I tied in with that subjective statement of hey, this can be good for certain apps. Do you guys think that that's the right thing to do in this table, or should it just be very objective where it just states the obvious of it's limited by local components? Yeah, I don't feel too strongly about it. I mean, it does strike me that each one of the cells in that table could justify a whole paragraph almost. As you say, there's quite a bit more to say there about performance of local disks, and maybe that's something we want to add in the second pass or later. I think what you have in that particular cell right now is good enough for the size of the cell. I'm sure it could be done differently or better, but we have limited space and the intention of this table was that you could scan through it and you could say, oh, how does the performance of local versus remote versus distributed box doors compare? I can just read three sentences in the bottom row of the table and I get a reasonable idea of some generalities that may apply. It was sort of my thinking when I don't remember Alex, so I put this table together, but there was my thinking around these tables in general. Okay, so it sounds like just like an objective statement quickly in a few words and then a little bit of subjectivity that gives some hints as to the direction that we're thinking or helps them understand the rationale then. Yeah, I would also, one thing I found that people struggle with is actually understanding what the magnitude of some of these differences is. So putting some concrete numbers in there might be useful. So like the durability or something like that, like the availability of like nines or something like that? Yeah, you know, performances, yeah, exactly what you described, performance of local disks. Everybody knows I think this one is at 100, I opt for something per 10,000 per 60 or whatever. Remote disks is, you know, all this is magnitude more than that. Yeah, it gets a little bit more like on the local side with NVMe, it gets a little bit more complicated and the numbers change. So that's why I had a hard time putting in some of those types of details. Yeah, it is hard. I guess just knowing whether, you know, additional overhead in network transport is a 2x factor or 200x factor is kind of useful. Right, okay, that's what I was looking for. Thank you for that feedback. So my expectation is that I'll be working through this and I think I'll skip over to the NAS table and then I'll start writing more details in the descriptions and the appropriate sections. So I feel like it all makes a good progress this week. Yeah. So where were we, the last time I heard was that you were going to run through the block for feedback? Yeah, so I just did some feedback on the block and I'm pretty clear on on how to fill out the information based on Quentin's feedback. And the next one is going to be file system for the table and then I'll go and fill in the descriptions after that. So I feel like we'll make some good progress this week. Okay. We do have, so we have one more session on the 8th of October and then we're sending out two comments to the wider, to the storage working group on the 26th. Do we want to try and target the 18th or the 19th as when we send out the emails that we give a few days to collate feedback and we can discuss at the working group? I would love to target that date. I'm just whizzing through the document here. It's difficult to read it because it changes every time I read it, so I'm not quite sure which parts to reread, but it strikes me there's a lot of content missing still. And maybe that's just subjective, but so Volumes, are you doing that this week, Clint, did you say? Yeah, so I'll commit that for Friday to have my session done, so blockstores and files. So I'm committing to have basically all of the attributes and the storage layers completed by tomorrow. So sorry, which section is that? Is that the one called storage stack slash layers? Yes, correct. Okay, so that's another big missing piece. Okay, that'll help. And the next page, I guess. And the next. So then the next section, the orchestration and management interfaces, I think, I'm seeing has done an amazing job and that looks fairly ready to me in terms of being ready to review. Then Clint is working on the blockstores and the file systems this week. Who was working on the object stores? Is that yourself, Clinton? No. That's Louise. Oh, that's right. I'll pick him an email as a reminder. Sorry, I'm struggling to, this document's kind of getting large. So maybe, can somebody want to just present? Sure, I can do that. And what I was thinking of doing was actually scrolling through the document and just it's, if you just go through the table of contents, it's kind of difficult to get a picture of what's done and what's not. Can you see the doc? Yeah. Okay. So the scope and the layout and the attributes of the storage system are done. Okay. The the data access interface was what I was working on just a second before we joined the call. And I'm going to finish off. Okay, hold on before you just go back up again. So volumes, block file system, shared file system application, API, object store, key value store databases. So volumes is what Clint's going to do, is that right, including block and file system? Correct. So that is just a 30 days of description to kind of say, this is what block is, this is what file systems are. So it's not too complicated. That's like a part of each. Yeah. And then the the storage stack of the layers, this probably means it's probably about half a page of content per layer, if I need to add in. How about you skipping over lots of stuff here that's not finished? Hold on. Sorry. Yeah. Is there a section that I'm that I'm not thinking about? Because when I assign myself from the from the initial list, it was like right now the page is what 23 and 24. And then I see there's like an empty volume section. So when you said volumes, were you referring to the block stores and file systems or referring to something else? Yeah, like that, volumes, who's assigned to that? No, this is me. Okay. I'm going to fill in this. Yeah. So you had the blocks in the file system section, correct? Okay, sorry. The storage layers, that's me as well. And I'm filling in these sections. I think I need there's about probably half a page of content for each of these that I need to finish off. So there's six sections here, which needs filling in six or seven sections. And then Alex, how is this section different from the latest part? Is this a more refer description compared to later the later sections? So this this section defines the different layers in in a storage system. So we're talking, you know, we kind of said, we want to differentiate the layers so that we can define common terms for things like the data protection and the transport layer and all those sort of things. So then the file system, the block, the object sections can can be much prefer because they don't have to define the data protection multiple times, for example. Okay. So I'm defining these layers. I'm not going into what a file system is or what a what a, you know, or examples of a file system or examples of a block storage. That's in the block section and the file system section, which is later. Does that make sense? Yeah. Okay. So I finish off these layers by tomorrow, hopefully, and then this section, the orchestration and management interfaces is the section that that Xenia has fleshed out. I think she did that last week, correct? Yeah, it's done. Yeah. So and this this covers native interfaces and the top volume interface and external interfaces and other framework and tools. So we have some sections for opening, sorry, open SDS and Rex Ray and Rook. Just one quick comment there, Jing. This is, I think, where things start getting dangerous, where we mentioned some projects and not others and some products and not others. So just a heads up there, I think. Okay. So what is your suggestion? You prefer we don't mention them at all? Well, I don't know. What I know is once we open this up for review, people are going to say, why is my framework not there? So we either have to have an answer that says, you know, we only mentioned frameworks that are in the CNCF, or we have to say we only mentioned frameworks that fulfill some other properties, or we have to mention all the frameworks that people want mentioned in the document. And I think I'm just telling you that you're going to run into that problem. I'm pretty sure I don't know what experience and I have this, but that would be my prediction. So Alex, what's your thoughts on this? So we're never going to make everybody happy here, whether it's on the orchestration and sort of framework tools, or whether it's in the examples we give in the block section or the file system section or the object store section. I think we have to, I think we have to be pragmatic and focus on some of the main things. And possibly we can use the CNCF landscape as sort of criteria as to whether we put data in or not. But again, right, we can't put every single system in it. It's pretty simple. There are lots and lots of systems. Yeah, I think like devil's advocate side, people, like if we took certain things out, people are going to look at it as incomplete, possibly. And if we're describing what's going on cognitive, we don't list any projects. And people may think that we're just missing the boat completely. I think we're damned if we do, damned if we don't on any side of this. So it's really tough. And so I would go with some type of a description like Quentin had suggested. And maybe it's that they're a CNCF project. Maybe it's that they've presented to the working group or presented to the TOC. Maybe it's some type of a statement like that. Yeah, I wonder if another approach isn't perhaps to just have extremely brief descriptions of these projects with links to the more detailed description and then categorize them, because some of them are going to be, presumably you can break those frameworks down into categories of some sort and essentially make it open to just about anything. Just a thought rather than neck three and describe them in a fair amount of detail. And then have to explain why we're not including the other 300. Okay, I'm exaggerating. Is this something that we can push back on the TOC and just say, hey, we're leaving the section open and here's our suggestion of the things we would include? No, we can't, because I am the TOC and I don't want to have to solve that problem. That's our job here is to solve that problem. Right. Is this important in this first round that we include these? Do you think that the first draft should just avoid including the projects and tackle out those like draft? Because the ecosystem is in flux, right? I mean, I think CSI is going to be GA at the end of the year possibly and things are going to change even more at that point. So maybe we can defer it to the next round. I just want us to be consistent. And I just want us to mention either only mention things that are in the CNCF and explicitly say we're only listing things that are in the CNCF or cover the landscape more broadly, which I think was our mandate here, in which case we need to cover more than that. So we did look at the landscape, but we can take a look and see if there's more that we should add here. Maybe just to make each paragraph just like one or two sentences and then it doesn't really elaborate on what exactly this is. My two cents. We can use any type of criteria and as we always end up being wrong. And the reason why I'm making this point is none of the criteria that we can ever debate on is going to definitely make this right. On a personal level, I don't think that saying that it's the CNCF project is a useful criteria because talking about object stores and not mentioning the object services like S3 or whatever from the cloud providers is kind of crazy. So I would strongly focus on making some pragmatic decisions. So we choose things which are in wide use to some definition of wide use, whatever that makes sense, but not the discriminatory. If somebody really feels that their project should be included, well, they can write up a paragraph and we can choose to include it or we can choose the link to it. But I don't think we should ignore the fact that the audience for this is end users and they want to be able to find out what the pragmatic solutions are. This isn't about sort of being the most fully comprehensive list and it's not about restricting who gets into the document. It's about finding some sort of medium which is based on what end users find useful and that is inherently subjective. So if anybody feels that they've been completely left out then and they feel really strongly about it, then we can always add a paragraph in later on. What if we just take the part about that statement which works me is allowing them to write their own paragraph because I think that they have the ability to say what they want and it can turn into a bunch of marketing and then we have to go back and forth with them about what they're going to say. What if we just break down the current storage landscape that we have that's published by CNCF and we just list where those projects fit and we just do a link to their project page. So we take the framework of whether framework and interface etc. tool and we just classify what we have on landscape and provide links to the project pages to get the description. I actually prefer Alex's proposal and that's essentially what I was trying to say and Alex said it much more eloquently than I did which is we need a criterion otherwise it's random and we're going to have meaningless arguments with people about why we included one and not another thing. So the criteria that Alex suggested is most widely used and that's subjective but you know the editor has discretion as to whether something classifies as widely used or not sufficiently widely used to make it into the document but at least we're telling people that's what the criterion is and we can say in the document the following are some of the most widely used storage systems and then we you know perhaps give a brief description about each one and then one way of doing a catchall for the rest is to say other systems that we're aware of are the follow and just have a you know a list a comma separated list of links to you know other stuff so and if anybody wants to claim that their thing exists and we could just put it in that list and that way they can feel they've been included in the doc but we don't have to clutter the doc up with descriptions of things that are not as much interest to the rest of the reading public of the doc. Does that make sense? Yeah. Yes. And Clint just to be clear what I'm trying to avoid is one of the I mean we actually have a duty here to the readers to provide value and filter through all the noise and stuff and I think if all we're going to do is like enumerate all the storage systems that exist out there I think we're not doing in that service. I agree with you and I guess the the the source that I was thinking about was what CNCF has already published I wouldn't say everything but if if Dan and CNCF has decided they want to put this thing on the landscape then yeah we can tell people why it's on the landscape but that's the only thing that I was thinking about and yeah. So I mean if I had more insight into what's on the landscape and why it's there I might be able to get behind that idea but but I don't even know what are the criteria for being on the landscape. You're asking me or? Yes. From what I know so far I had to do at the funding level and whether Dan decided to put them on or not. Yeah that was my suspicion and that's exactly why I don't think you could use it as a source. Yeah I don't even think it's the funding level I think it's whoever raises a Github PR for the landscape gets in because there are a ton of projects on there which are which are not even you know members of the CNCF. That is by design but because there were complaints that there were very you know before Amazon joined the CNCF you know S3 wasn't on the object stores and people were like what the hell's going on here. Yes so I think we have a duty to do that if somebody can find out a more compelling reason why the landscape is has a curation as to what gets onto the landscape and what doesn't and if that curation principle is these are commonly used things that people want to know about then we can use it. I don't think that is the criterion in practice and so therefore we should just do our own one. By all means we can double check against the landscape and say is this stuff on the landscape that we forgot about. I don't want to beat this dead horse but uh goo are you out there I see you've joined I don't know if you were listening that is part of the conversation. Okay yeah let's move on but that's my commentary here is we need to be consistent about what's in the document and what's not and anticipate complaints from people whose technologies are not in the document. Okay so moving on we don't have we you know as predicted there isn't there isn't a huge sort of amount of information on application interfaces or management interfaces for for object stores or key value stores or databases you know there are some there's some work on this and obviously there are APIs available from cloud services but this is kind of one of the one of the points I mentioned in the differentiation which is certainly the volumes are a much more mature management interface and orchestrated interface than anything else. So then we have lock store section which which Clint is filling in and we have the file systems and then we have the object stores so so can somebody remind me oh yes there's really the one that's doing the the object stores I'll I'll I'll think him and then I'll think seeing as well around the key value stores we agreed last time then that's the database section will probably take out of the first version of the draft just because I see some why it's a volunteering for the database section I think the the same person who is going to work on the key value what is his name the shum he I think he added the you look at the beginning okay yeah I think he added a comment there say he can he can do a database section he added a comment somewhere in the beginning I got a message from him yesterday which I haven't replied to I'll remind him and ask him if he can have it done by the 18th all right could you could you copy me or not the email and just volunteer me to help or whatever if he needs to leave I think I did already and he did reply to it and he did copy you on the reply okay I'll reply to that then so maybe it's actually easier if you just chase him up reason being you're sort of coordinating all the people and getting the doc finished so I don't want to be out on the side road somewhere so yeah just reply to that email that you copied on and given the timelines and deadlines and things okay and then and then we have the we have the appendix which is um well we have some we have some data that their shiang has am I pronouncing this right is that shiang shiang yeah it's shiang is put those small comments there I think that kind of makes sense but yeah I'll resolve all that I have on my to-do list to add the two and three phase commit and just write a little paragraph under each of the other headings there and then I think the appendix is done all right so that's good that's the little doc yeah I guess my my big concern is that the actual body of the doc is largely empty there were many pages we scrolled past there that are completely empty and I'm becoming increasing you know we've been at it since May I guess and arguably the really important parts are totally missing so yeah we just need to it's not unachievable in the next week but we're rapidly running out of time that's a fair comment I think there has been quite a bit of talk to put into it and I think we can we can speed up I can certainly cover my stuff by Friday Clint this is where you and me having maybe a one-on-one call and you can sort of brainstorm some of the process to the block stuff that's that's how uh yeah if you if you want to if you feel like you've got some some input or some perspective that would accelerate my work then sure all right I'll ping you I'll ping you offline and just to decide the time okay okay does we have anything else to cover uh so let's I wanted to make sure that we're clear on the the timeline make sure that that's updated we were talking about the 24th that's being when the the next SWG is meeting and you guys wanted to send out something prior to the 24th to to let people review before the SWGs so that means on Monday or does that send it out uh the Friday before well I think Monday at the latest right so so we target for Friday that on Monday at the latest so like the 19th is when we want to send it out yeah and that basically means that next Thursday when we meet we'd be doing and go no go on uh on sending this thing out correct I I think um we should also kind of say that if one or two of the sections isn't completed in time we should still solicit feedback I think because we can we shouldn't sort of use the whole block being ready as the gates if there are certain sections which are which are ready to review earlier we could do that too yeah that makes sense to me yep I'll give it up cool all right did we have anything else on the agenda for the working group do you have anything else for us Clinton sorry I don't know if you can hear me I've lost a window here and I think I might be muted can you hear me oh we can hear you probably means you heard me chewing my cereals as well no I was just I was thinking of personally actually reading through the doc like the day before next Thursday because by then it should be mostly complete and largely in the state that it will be when we send it out to the rest of the group but I was also wondering whether yeah I mean we need to have some internal real review before we send it out I think so maybe others want to do roughly the same thing just go through all the content as it is ideally as it is by next Wednesday but you might only have time before that and at least make sure that you're comfortable with what's in the document or all provide any input if there's egregious stuff there yeah I don't think there is but you know I haven't read it all in detail all I've really been doing is keeping track of roughly what's done and what's not done and I flipped through the first draft but it's changed a lot so yeah that makes sense so we would just be communicating through email right are we going to have another meeting next Thursday or no yeah we have a we have a meeting on Thursday I'll send that I'll send that to you fine does any particular preference on time does this sort of time on Thursday work what you mean Thursday 11 11 or 12 what what time you're talking about 11 or 12 or 8 or 9 you're talking about so it would be 11 Eastern like luck today okay yeah that's fine does that work for you guys too Clinton Clinton yes next Thursday yeah let me take a peek yeah I'm good for that cool all right I'll send that to you okay and yeah make sure you invite Liang and and just touch base with him before so he knows exactly what's expected and by then yeah cool okay thanks guys all right thanks everyone thank you