 Quinn I think we're ready to get it kicked off whenever you are I feel like you know We've we missed a handful of meetings, and I think the participants of this plan are those that are focused on Being a part of the the white paper So I think until we make more noise about Working on it like I think this group is probably what we can expect to show up at the meeting right now Okay, that makes sense Alex do you want to kind of give us an overview of where the document stands at the moment and where you'd like to take it from here? Sure So so first off As you can see there hasn't been The rate of reverse that I've hoped that would have been I was just explaining to Clint I've had a really busy couple of months and Not had enough opportunity to put the focus on it with me But what I've done so far is a Restructured look based on What we had agreed previously so I've created Placeholders and the the sections that I think we need to to write up and I do have I do have notes that cover Sort of rough rough notes that I need to sort of type up that cover sort of pages six to 16 and I put in a section around orchestration and the management interface is starting at page 70 Which which acting as Has offered to help with as well And then we need to sort of fill out some examples in in the block stores in the file systems, etc sections But hopefully those will become much quicker once we have the The other terminology sort of named out and documented So what I what I'd like to what I'd like to What I'd like to propose is if anyone has any sort of Strong Feelings about any of the particular sections or wants to take ownership of any of those sections now would be a good time to step up Otherwise, I guess Xenia and I will continue to work on this now that there's a bit of structure in there And we'll see where we take this over the next couple of weeks But I think we probably need to iterate a little faster So I would suggest if we have two or three volunteers that will work together. Maybe we could have a call For half an hour every couple of days and just keep the progress guy Is a just a question for the group. I Mean, it's my first time coming back to it in a little bit and seeing how you guys have updated the structure Do we feel like? I Mean we're asking for volunteers. I mean, maybe we could get people to I mean What maybe we could have someone going and actually a highlight sessions that say like here We're looking for a volunteer and have like a comment and get people to sign up that way Or do you want people to sign up and just you know, take sessions of it and say I want to work on this? Sorry kind of another one follow-up is are we Do they were ready to actually like pare it down at all like is it is it clear that maybe some of what's in here Is it nice to have and not important for for the document to be in its first draft? I Since the objective of the document is to is to cover the terminology and to cover the layers and to cover the you know Get people familiar with what's possible in the landscape? I think Broad coverage is probably more important than Lots of depth on every point. So so I'd rather have I'd rather have a broad coverage of all terminology and And even if some of the terms are only defined by a few sentences or a short paragraph Then we can kind of flesh it out and add more detail in phase two or phase three or whatever But I think broad is probably better than depth at the stage One of the things I was going to propose is In the in the examples of file system and block device, etc I was going to take a first-class it Putting down some of those some some of the examples whether it's File systems or block devices or objects or sort of whatever else And even some of the databases And then maybe reaching out to a broader group to kind of say hey, you know Fittest is a project. It's a listed database. Do you want to supply two paragraphs to explain what Fittest is? And how it compares and you know, and how it equates to the rest of the terminology that we've talked about her hands, you know, data protection and consistency and availability and all those sort of things and and kind of just crowd sourcing the examples by asking the maintainers of those examples to actually add that data in Yeah, that makes a lot of sense to me your general approach. I would be supportive of that And then on the the first question in terms of assignment Would you rather go in and and grab sections of the table contents and say hey like I'm looking for someone to do this part or do you want people to go in and just grab individual smaller chunks and As I said, so so the the the first the first bit so the attributes of the storage system the main access interface on the storage second layers I do have a bunch of rough notes with which will mean I can probably get this done in a few days or maybe a week or so and then I don't know. Are you still comfortable picking up the orchestration and the management interfaces section? Yes, definitely. I can help with that Availability Jing You have enough time available I'm just wanting to make sure I know you have a lot of other things going on in your life You are you comfortable that you'll have the required time to put a dent in that in the next week or two. Yeah Okay, great So I'm in the table contents right now Alex, and I'm just trying to make sure I'm doing this accurately So I highlighted the sections between attributes and ending before the orchestration and I Is that accurate? Yeah Does somebody want to just present that document so we're all looking at the same thing I'll share Can you see that? Yep. Okay, so we have the first the first section covered to me in the second section of my orchestration management defense to Xing now With the With the blockstores and file systems. I'm thinking that we We just need to come up with a list. I can I can come up with the list and then we can form out We can ask, you know individual contributors to to other paragraphs to cover this so I could reach out to Aaron or Steve at Red Hat to give us something about Gluster and Seth and I could reach out to the sound give us something about Rook and Yeah, I'm here Sorry, take it This is Louise so I can add some stuff if you need. Oh, excellent. Yes, so we can cover portraits of those things too You guys want me to own this session the blockstores and file systems and then I'll Reach out to folks to get them involved Yeah, that would be great. Okay. I think and this is a question to the group My thinking was that it would be very useful to have Generic statements about Fundamental properties of local blockstores, you know remote blockstores, etc And not just have a sort of laundry list of products I think it's great to add add the products there as Examples of whatever category of store we're talking about but I think it's as important or more important perhaps to have the fundamental generic Statements about these classes of store Jose. Yeah, actually Actually, I completely I was thinking the same thing just a few minutes ago And I'm glad you mentioned that because sometimes what am I my concern is is as we continue forward and this document becomes a live document for every new company that comes in and adds a little section to it so it becomes like The sections with the companies become larger than the generic session that which is showing The reader what you know trying to teach them what what storage is so that's my concern. So maybe we can You know, I understand that we sometimes need examples I'm not don't know the answer to this. I don't know the solution, but I do feel that the generic and the Methods of how we provide disinformation to the reader is very important Come completely completely agree and and I think, you know, this is why I opted to have to document the store stack in the layers and the access interfaces upfront And say this is what a block. This is what the attributes of a block access interface I this is what the attributes of the files as to my access interface are and the share files system, etc but then also the different layers in that and part of that is about you know having local and remote and The different apologies and whether chargers or low-balance or all those things So that's so that's when we when we then come to the block section and we say this is local block We can we can quickly make a reference back and say local black look local block has these attributes around Availability scalability performance consistency durability, etc. And remote block has these things and distributed block has these things And then we can give some examples, but we don't have to we don't have to We don't have to sort of re-explain ourselves each time because a lot of the a lot of the layers are The terminology remains consistent across all the examples then Yeah, sounds great. So I guess the question is How do we flesh out these remaining sections as quickly and I really really like the The stuff that's in the doc already. I think it's it's the right approach to Presenting all of this information I'm just as I mentioned in the email to a couple of you. I'm concerned that That we're not gonna get it done in the next Let's call it four weeks five weeks and so Yeah, I guess the question is how do we fill in the missing bits to particularly towards the end of the document which are arguably I think the groundwork that's been laid on terminology and The approach to analyzing and presenting these things is very valuable, but ultimately It's the end of the doc that that that benefits from all of that and So, you know, one approach is to take to find volunteers who have specific Expertise in these particular areas, you know, Basam is perhaps a good example for block stores I think Rook was originally designed for Seth And and now is supporting other things but but find people who who can talk to the generic sections Before they perhaps go into any particular products or projects. It obviously has the Risk that the people who have a specific block store product or project Will perhaps be a little biased in how they present the generic information, you know, not Not intentionally, you know distorting the truth, but but just they have a particular perspective which is perhaps walked by one particular product, but I think If we get the right people with the right skill sets, hopefully that will not become a material problem Figuring out how to delegate and get other folks involved to help fill this out is gonna be important the other point I want to bring up is The things that have been assigned to Alex me and Shang Those are relating to, you know, the lower level like unstructured block and you know file Systems below that that we don't have assigned is the more structured so object stores and key value stores and databases And you know if we're gonna try to pair this down to actually get it done unless we have someone stepping up on the call like right now to To tackle those last three then maybe we should be deferring those for a party of the dock What do you need me to do? Uh, well, we need to get someone signing up for other things. So I mean, I'm signing up. So What are your sorry, I'm not I don't know you well, what is your sort of core background? Well, which areas are you most interested knowledgeable about? Oh, I've worked DMC for 13 years at net up or three ever had storage for three and now work out what works I've worked on object stored key value stores block stores file systems. So you could put me on wherever you like So either we stand and like tackle more of that structured area get Lewis Lewis in there Or we ask him to help on one of the other three sections. So we have close We we have an immediate needs for object store and key value store So if if you want to take a stab at time to lose that would be really helpful Great and and I would personally be comfortable if we defer databases I mean, it's a big enough area and specialized and most people know what a database is and roughly what it looks like So I don't think that area will be as valuable as some of the other the other two you mentioned For completeness we want to do it eventually, but I think it's arguably less Which people are much more vague about understanding what these things are What's your email is so I can get you signed here Luis at port works Come but actually I'll just take objects doors. I'll leave key values to somebody else If we can Maybe find somebody from the xcd team I was just thinking exactly the same thing and I happen to have contact with the original author of xcd Fairly close contact so I could reach out to him and ask him if he could have a stab at that section Yeah, it CD is not strictly a key value store But but I think he has enough solid knowledge of that area To be able to have a good first pass at it Okay, that makes sense Yes, I can take that one is it to do Alex would you like to have a kind of an intro session with him just to Sort of frame the whole effort and make sure that you guys have a common understanding of what the intention of that section was Definitely Yeah, one thing I want to avoid one particular failure mode. I've seen in the past is is like documents written by committees Where there isn't a sort of a lead thinker who's structuring the whole thing because they can as somebody mentioned earlier They can end up as a more like a dictionary of products and Yeah, I definitely want to take away I definitely don't want this to be a dictionary of products because This document kind of fell apart this time last year Soon as we started trying to work on who's seen and who's out and all of that sort of the base So so I you know listen learns. We don't want to do that again And you know, I'm happy if say between Clients You me and sing or and Louise, you know, we keep like editorial control over the document It's Keep it saying I think we can do it a good job. Yeah, I think once once the guts of it is there you know, we should definitely open it up for comments and and I'm hoping that we'll get some valuable input and many of those will result in changes to the document. I'm sure but it needs to keep the general flow and structure saying otherwise it can be a bit of a Throwing stuff against the wall. Cool. Excellent. I'm very comfortable with the way things are moving if we can just be very conscious of time constraints and Maybe calls a week or something just to keep keep the momentum going would be Yeah, I was just thinking on could we could we maybe have a call and say Thursday or Next week Monday to Wednesday is bad because there's the already velocity on Probably going to sign up the package if if we can do maybe Thursday any time works for me Thursday in the week As in tomorrow week. Yeah. Yeah, I'll leave the logistics up to you guys All right, you want to keep track of that in the top of the dock for now the meeting Okay There's two more sections in here that I don't think we have people sign up for There was a storage orchestration management and the appendix. Oh Actually, that's storage orchestration management that needs to go because that's moved up to the top That's the that's the one that actually got assigned to me, I think It's just there's a there was a head there there, which just needs to grab it. Okay. How about the appendix? Appendix was was something I threw in there and it was really just generic Algorithms technologies, etc. That that apply across many of the areas So it was really a grab bag for stuff that didn't fit cleanly into any other section It may be that it's already covered elsewhere or again, perhaps we can defer some of that stuff So basically something on something and it does end up fitting into the section there in the middle Yeah I think so, I mean I think It's like consensus algorithms could well Yeah, maybe we can I did add a bit about Catering and consistency so that's probably covered but I Can take it and it's I know I know a fair amount about all of those And I can do a very I mean, I'm not gonna go, you know into great detail. I might put a reference to the pexus paper and the rough paper and Basically just have a you know three line item for each one of those to explain the essence of them and how they differ That's that's good idea. I think we can also we can probably move that and further up the dock into the storage layers I'll move that further up because Consensus is something that's common across, you know objects stores and key value stores on databases as well Yeah, I'll just wherever the sections lie at the moment I'll just fill the guts in and then we can easily move things around later relatively easily I mean is that is that guidance from everybody here on the call like as we're filling in these sessions that You know, we don't need to rewrite what's already written in detail I think a few sentences something meaningful and a link to an established and you know credible source that describes a tech is better than trying to Rewrite it from scratch Completely, yeah You know like I'm not gonna I'm looking to Rewrite, you know the definition of rain there was something like that. There's enough Me no official articles in that already. Okay. I think that the one part that is pretty important is Being able to sensibly compare some of these things against the properties that we've mentioned and You know, there may be links to some subsets of those comparisons But I think at the end of the day having a consistent those tables that we Provisionally put in there. I don't know what is Alex. Does it make sense to continue to plan to fill fill those in? Yes, what Yeah, I was Yeah, I was I was kind of good to think about this maybe slightly differently I had another table which I haven't copied in yet to to say To make a table based on the layers rather than the attributes because the layers actually define The attributes in most cases so so as As I'm writing down the layers you you'll see I've kind of said for example Sorry for all the screaming around but like If like if access interface it defines how we access the storage system But it also influences availability of performance or scalability in different ways And therefore by saying a local file system or a most fine system implements the data access layer this way It gives you a better way of showing how Define those those specific attributes rather than listing at those attributes every single time because otherwise they become to be for For the various examples so so for example, if we just say a local file system does this We don't stick into consideration some of the other properties which affect those attributes Because many of these systems are layered. So for example, you know, you look at an RPT device from Seth, which is a block device And it's and you can argue to distribute a box device but it's actually based on the Seth object store mechanism and The Availability and the data recovery the data protection is all down to the layers of Seth as opposed to the block device itself, for example, the block device is a data access interface Does affect availability in terms of how you move that block device between nodes and the management Interface that block device. So I was thinking of finding in those terms is supposed to just done just a raw table of the attributes So kind of saying with the local file system. These are the layers And this is how it affects the attributes because each one of those layers changes the attributes Yeah, yeah, I think that's fair The one thing which I thought when I knocked this thing together and to be clear those tables I bashed out in five minutes. So I didn't give any deep thought to them but what I thought was valuable is I Think it's more about distributed versus sharded versus local That that has pretty fundamental Effects on those properties Whichever layer you're talking about and you're absolutely right. There are different ways of building a distributed block store Whether it's on top of an object Store or something else But you know once it's distributed it is fundamentally has a set of properties Yeah So maybe yeah, and maybe we're saying the same thing Very keen to so I think the The properties of a distributed block store verse. Well, yeah, there's maybe two different interesting aspects. The one is Big by virtue of the interface A block So the point I was trying to come up with was It's less about where there's a distributed object store or a distributed block store or distributed files system It's the fact that if it's distributed with With a razor-coating for example, then there are implications on The number of notes are implications of latency their applications on Peter recovery and all those sort of things what which which apply equally whether it's a file system or a book device or an object store and Then on top of that you have for example the actual interface Which also defines? How you can Availability in terms of failover or something like that. So for example, if it's a if it's a if it's a shared files system interface on top of a distributed store Then just have to move them out points if it's a if it's an object store on top of a distributed store Then it's about maybe load balancers or having multiple service access points in terms of for the availability But not redefining what a distributed store is for each of those Different Perfect sense. Cool. I Added at the top so I wanted to chat about just make sure we're clear on the timeline if you guys are ready to move on to Organizational part of the document Let's you want to tackle more of the content in the top for everybody is Meetings weekly while using the SWG on the bi-weekly If that's what we want to do there it is we can change it for whatever one wants to do And then the other thing to chat about is the you know, what's the status update? Like which to see are we targeting to to let them know What status that we have this document? So I think there's three things we got to decide one, you know, what's cadence of meeting moving forward to What's the the timeline? So what are our delivery dates and you know, what status should this document be as we get through our timeline? Yeah, that makes a lot of sense to me the one thing that stands out there is I would really like to Distribute this document to this group for comment before we present it to the TOC I wouldn't If we have time I mean, we should we should probably aim to have a draft to the working group for the for the Wednesday 26th over Session rights that makes sense to me give them A week a bit tight I would like to give people longer, but but a week or so to give some comments and you know throw the hands up in disgust if they don't want us to present anything Which I hope won't happen and then present the current status to the TOC at that proposed date Which is about from memory of about a week and a half week before Kubecon Shanghai Sounds like between the 1026 meeting and the TOC update it would be two weeks Almost two weeks or two weeks and do we want to move from draft one to draft two within that time? Or do we want to say that we just submit a draft one for comments? Or you know, what do we want to be? I? Think the latter would be okay given the time constraints we have okay So when so for Kubecon China then do we want to have a Draft or a final Where should it be by then I? Think we should we should have a Final draft as close as right by then yeah, I'm a little hesitant to Fall foul of Not giving people enough time to review and comment And presenting it as final before everyone's had that opportunity So I would be slightly more comfortable saying this is our draft. It's currently under review Please, you know Give it some thought and look at it and maybe present the final one in Seattle a month later Yeah Because I said draft two at China and final for Kubecon US Yeah, I mean my thoughts are that that sounds reasonable Alex Yeah, that sounds fine You give it a chance for the TOC to get involved if they want to as well get their feedback and include it and They get the final one out there after China, so I agree with that I don't know if this helps I know you're preparing a presentation for for the Kubecon China I actually sort of presented the rough outline of this document to meet up a couple of weeks back and Put for the presentation with a handful of slides together So I can I can show that to this group and you know, we can maybe use that as a starting document for the presentation to So you keep on China if you think that helps That sounds fantastic Cool Shin, are you comfortable being the sort of primary presenter in China? Yeah, sure, you'll be there too, right? So it's a yeah, we can we can co-present I just think you're a better presenter than I do and you certainly have a lot more knowledge in this place I'll be there as the pointy-haired to see member and you'll be there as the storage expert One other Comment I had about the document in general is that I think the level of detail in the dock is very Good at the moment. I don't think it gets to be detailed, but there's quite a lot of kind of meta discussion around Options we considered Etc, which is valuable, but I think we're gonna have to condense this thing into something much more consumable Because the vast majority of the audience Consuming this I think is not gonna have the attention span to be able to read a you know What looks like it might become a 50 or 60 page document so I'm Thinking that we need either a slide deck Which the majority of people can consume and I'm thinking 20 slides or something like that that distills the essence of this stuff And then says if you want more detail go to the document Because I think the document in the shape that it's currently panning out is Too big for the vast majority of people to consume It's more like a reference guide, right? They'll just skip to the chapter they're looking for Yeah, yeah, so we will probably need an executive summary at the beginning of the document Or something like that and and perhaps a slide deck It says if you don't want to read a 50 page document read this 20 or 20 slide deck Yeah, that makes sense We like try to Make the the cube con china presentation the beginning of that That effort to condense this information into the slide deck Yeah, and possibly even the TOC presentation before that Okay, so that's about eight days before that. Yeah Cool sounds like we've made some good decisions Good stuff Good anybody else on the call want to want to step up and take any any more of this document If we've got Matt Brad blaine you guys out there. No all good Okay, can I ask you Clint to perhaps just send a summary of what we just decided To the mailing list. Yep. So that those who are not here Know that there's progress being made and and who's doing what and what the timeline is and then maybe if they have the Bandwidth could volunteer as well so you can solicit volunteers It seems like we have enough people right now. Yeah, so we're not desperately looking for a hundred people, but you know, I think it's Good form to at least let people know what's going on and invite them to participate if they want to I think one of the things that also challenged us in the last round of the document just to think about last year was People jumping in kind of last minute when things were baked and and the Alex said we want to have more of a Dictorial control of of this document. So as I write that email and I say hey like get involved Is that fair to say like now is the time to to step up and What's the what's the friendly language to basically say like? Well, I think they're different ways of going about I'm quite in favor of having a very limited number of people with edit control over the document And it sounds like that number is is like four or so at the moment and then Commentary we can allow people to comment and then you know Their comments may or may not make it into the document and that's at the discretion of the primary editor But have that, you know Transparent and out there so people can make comments and the primary editor can say thank you But we've deferred that to the next phase or we're not in on products or whatever the case may be All right, so like I guess I get break it up in phases to say Hey, we're looking for contributors right now for the document and then the timeline dictates that you know We're open for commentary from anyone at this time and etc. Yeah Yeah, and and the you know, there's the scope of the documents kind of Outlines what we're doing now. We're doing later as well. Okay, I would I'm not sure what you're thinking is Alex, but I think the document is too premature for commentary at this point I think there's just too much missing. So I would I would say we close it's not open for comments But if you if you want to volunteer to write One of the sections, please contact Alex something like that. Yeah, that works Cool, and I'll follow up with with the intro for the key values, though Okay, okay Excellent. Thanks everyone. Yep. Thank you Alex for all the great work here. Yeah, thank you guys. We'll catch up on Thursday Thanks guys. Bye