 Good morning, Jing. Good morning, Ax. Well, or good afternoon. It's just us at the moment. Yeah, things probably, seems probably getting quiet after Kupka and then holidays. Yeah, I'm looking forward to Christmas. So about this dragonfly due diligence, now is it up to us to do it or is it, did I still need a TOC member to do it? I'm still a little confused by that part. So the background to this was that dragonfly had presented to the TOC and they and the TOC said it would be good if the storage SIG could do a review. So dragonfly then presented to the SIG and we had some concerns and we had some queries, which was documented by the project team, but we never actually formally put our concerns or sort of queries down on paper. So I think it's basically on us to document them at this stage. And I was, I was just going through the recording of their presentation to kind of remind myself of some of the, some of the queries. Okay. Hi, Aaron. Hi, Suga. Hello. Hi. Hello. Hi, Steve. We have fame as well. Quinton said he was going to be delayed by a couple of minutes. He will be joining. We'll just give it a couple more minutes. It looks like you have a nice view, Alex. Yeah, it's not bad. Although it's already getting dark here. We'll just give it one more minute. I have received a few apologies already. And Quinton said he was going to be a little late, but apart from that, I think we should be good to go. So, so, so let's start. The first thing is, if you could all open the meeting minutes, which I've put into the chat window. I've put like a little clip at the beginning of the meeting minutes to kind of have a running status of things which are things which are on deck for the SIG. This is something which I'm hoping the coaches can keep up to date and that's why we have an easy way of updating the TOC deck when they need an update. But also helps us with, helps us to have a quick reference of things which are in play at the moment. So the first thing on the agenda is, which I'd like to bring up is the Dragonfly project. So just as a, just as a refresher, Dragonfly presented to the TOC in August. And they, the TOC said that they needed some input from the, from the SIG to help with their, with their process. So, so Dragonfly is a little unusual. It's, it's a, it's a container, container registrar or registry, similar to, to sort of the Quay project and Harbor, I guess, in some ways. Although it's, it's sort of a more generic file distribution tool as well. And, and therefore, you know, there was some confusion as to which SIG it would actually fall into, but they, but they asked the storage SIG if we could have a look. The, the project presented to us on the 28th of August this year. And in the meeting minutes, you'll find a link to the, to the recording of that presentation. In the presentation, we had some feedback and some questions which, which the project team collected in a doc together with some answers. But I don't think they captured all of the, all of the questions that we had or all of the concerns that we had. Now they've raised the PR and the due diligence doc to move from sandbox to incubation and I'm just concerned that since we haven't formally replied back. Our feedback might be missed. So I was, I was hoping that anybody who has some notes from the presentation from back in August and I realized it's been a while now. Or if you have time to re-review the recording and put some notes down together. I was just in the process of doing that, of doing that today and I'll share them rounds with the, with, with this team. But I could really do with one or two other people just, just trying to, trying to have a look as well and reminding themselves. I don't know, I don't know who else was present. Was it, was any of you, were any of you guys present at the presentation that they did on the 28th? I think I was Alex and I, but I will listen to the recording again because. Yeah. I don't feel like I can give constructive feedback. No, I know. I, I, at the time I had just done some notes that there were some security concerns and some question marks about consistency of files and things like that, which, which I think probably merits, merits sort of being brought up. You know, even if the project team sort of turns around and says that they're working on it, that's, that's probably a good thing. But at the time I recall that we had some, some question marks whether it should move forward into incubation and I don't just, and I just don't want to talk to kind of move forward on all the pilots just because we haven't provided feedback yet. I thought Quinton had some reservations about it. So I think we should make sure we capture that. Okay. Yep, I agree. Do you consider security review? Not until you go through graduate to graduation. Do you go through the formal? Oh, okay. So that's not required for incubation. Okay. Correct. But that's a good point. By what measure do we look at that? Is it worth taking our concerns to the security seg? I don't know. I mean, I think that process is still being formulated. I don't think it's a bad idea if they have time, but I don't know what their backlog looks like. Yeah. So I think, you know, the bar to move to incubating is, you know, at least we have to feel that it's going to add value to the field. And I think if there are some sort of significant concerns either around sort of things like data integrity or security, I think it's worth mentioning them. Because, you know, there's no harm in the projects remaining in Sandbox for some more time if they're able to address some of those issues first. Because incubating does kind of put a CNCF stamp of approval on it. And I don't think the CNCF should be kind of approving things where there are concerns from the tech leads, or at least that will be my hope anyway. So, so yes, so what I'll do is I'll put my notes together in a Google doc and share the link out to the to the mailing list. And if anybody else can then add on to that, to that doc that would be really appreciated. And then we can link it back into the into the PR for the project so that the talk has the information. Any other questions on that specifically. Okay. The, the second thing I'd like to, I'd like to just provide an update to to the rest of the, to the rest of the team is a bit of an update about some of the process and workflow. That's that some of the process work for discussions that we've been having so an Aaron, please keep me honest here. We, we had some, we had some initial discussions before cube con and Aaron had put together a sandbox process template, which, which had some discussion in the talk, and then we had a face to face meeting between the different sick leads and and some members of the talk while we were at cube con and Liz has put a document together to to to a minute, some of that meeting. And following that, she only who's the, the talk liaison for the storage SIG has has said that it would be a good idea for us to, to have regular updates and regular discussions about some of this so that we can we can formalize some of these processes and workflow for things like doing project reviews and providing feedback into into the TOC processes. So the first, the first meeting with which Yang will be straight after this sequel. And we'll keep the, we'll keep the team updated with with any updates that that happened there. Aaron, do you have anything to add to that. No, I think you gave a great overview of it so thank you. Okay, cool. Oh, hi, Quinton, I see you just joined us now. So, Quinton, just just for your benefit, we had a quick discussion about the dragonfly project we were, we were with agreed that we're going to collect some notes. I recall that you had some concerns when we had originally seen the presentation of dragonfly so when I circulate the notes. If, if you could add to that or annotates the notes that would be useful. Sure, I'll be, I'll be glad to do that. I'm very happy to on that topic as a general topic I was just thinking about this. We've we've dropped the ball on a couple of these things and some of them are probably my fault. So this is not not blame storming by any means but I was wondering if we don't want to elect a secretary as in as an accompany secretary I don't know what the term in America is but I know in Europe they have this concept of a company secretary. And who just kind of his job is to make sure that the company like it does all the things that they're supposed to do on time. You know, things like filing regulatory stuff and financial statements and this and that the next thing, and typically runs the board meetings and things like that. Do we want to perhaps elect a secretary whose job it is to make sure that that we record everything that we promise to do and that somebody, you know, gets allocated to do it and it gets reallocated if necessary all that kind of stuff. I mean, if one of the chairs wants to do it that's fine. I don't personally have have the time to do all of that stuff. And I suspect that some of you don't either. And so maybe we want to elect such a such a position formalize it in the sink to just sort of opening the idea for comment. Um, I don't think any of us have time but I think it's needed but I don't know that it has to necessarily be one person all the time, I guess is what I would yield to I mean I told Alex I would, you know help by being a co lead, by rotating through creating the agenda and providing status to the SIG maybe if we could or the tech leads could help rotating doing that. You know, taking action items from a meeting and following through and we just have it is like round robin I don't know just a thought because I know everyone's equally as busy. I don't want to just pile on a bunch more responsibility on the one person. And I was testing a new an additional person so not not the chairs or the SIG leads. I mean that the problem is with these rotating things, unless some individual is kind of like keeping tab on on who's actually doing these things. They fall through the gaps which is what's been happening. And, and as I say this is not blaming anyone and probably as much as anyone else. But you know if everybody's too busy to do that reasonably simple job they're probably too busy to make sure that it gets handed around properly as well. I think, I think we, I mean certainly look with track and fly with with, well, it's lifted the cracks we moved, we moved on to other tasks before finishing off that task basically. So, I mean there are two things I think we should just become more disciplined as as a as chairs, which is one. We should probably, you know review the previous meetings minutes and make sure that we've closed off things and if we haven't keep them on the current list. The, the other thing that I've done just to keep things sort of semi saying is at the top of the meeting minutes I've just added a list of things that are in play. And I think we should keep that list of things which are in play at the top of the meeting minutes. As I'm just updated for doing it for at every meeting as a simple way of just not losing track of things because I think what happened with dragonfly is we just moved on to other stuff and forgot about will. I mean, Alex, I feel very guilty that you, you are carrying a lot of the burden of the SIG in general you're doing some of the work that SIG leads and certainly some of the work of the other chairs including myself. But I mean, conceptually I'm totally fine if you're basically taking this job as as company secretary, but I really don't want to, you know, overuse your your charity with regards all of this work. I don't think it's, I don't think it's a, I don't think it's a big problem. I think if we just keep this the work in progress updated will things won't fall through the cracks. And it feels like dragonfly is really the only thing that's really fallen through so far. Yep. And I will rotate with you every other time on that Alex, I'll do the SIG update as we talked about and I'll do the agenda. I'll switch off. All right, so then at least it's half the work and maybe between the two of us we can make sure stuff doesn't fall through the cracks but I agree this is I think this was an anomaly. It was a super busy time for everyone so we'll just make sure it doesn't happen again. Agreed. Okay. So that's dragonfly. That's the work, the person workflow. So recap of the work in progress. I think some of this stuff is, is a bit slower than we had hoped mostly because of cube common Thanksgiving and a couple of other things in the last couple of weeks but I just want to do a recap of the other documents that we have in progress right there. So just going from back to front the database doc that SIG was updating, we had had a fair amount of discussion and we've loaded up the document with comments. So I believe you were on the case to the comments into some paragraphs, right? Yes, I will find time for that in the next one or two weeks. All right, that's really useful. Yeah, I mean if we can aim to, so the next SIG meeting is Christmas Day, which obviously means it's not happening. So the one after that will be the one in the first week of January. So if we could try and target sort of mid January for some of these things that would be really good. Similarly, on the performance and benchmarking documents, I've put some work into some of the content around the things to watch out for. And Fatim has put in some of the information for the database benchmarking. I know Nick Connolly is working on the volume benchmarking section. There is some progress, but it's obviously slowed after KubeCon. So we'll be following up on that and again try to get something for the middle of Jan. And then we have the use case doc. I don't know if it's Luis on the call. No, Luis isn't on the call. So in the use case doc, I think we talked about last time we added in the information to keep the use cases somewhat generic, but also provide information from multiple projects. And we had a bit of a debate about how to make sure that this wasn't seen as some sort of CNCF endorsement, but the main point was that what we were talking about here was patterns and not endorsing specific projects. So we were talking about having use cases for perhaps specific databases or specific things like I don't know Kafka or Prometheus or at CD or whatever else. And I'm saying, you know, based on the attributes from the landscape and based on the types of the different types of storage that we've identified, those would be the appropriate patterns to use to say optimize for performance or to optimize for consistency or whatever else. And there may be more than one option. And I went through and sort of re-listen to the minutes just to make sure I was clear on this. We agree that there might be, that there will be more than one option depending on different optimizations that might apply for those particular use cases. So I know there was a lot of debate in the previous call just before KubeCon. I just wanted to make sure that we're kind of all on the same page now and there isn't anything else outstanding because I'd really like to get some of these use cases documented so that we have two or three examples and then kind of share it out to the wider community in the hope that we get a bit more feedback from that. So this once we have a few templates. Is Luis still leading that then? I mean, whose responsibility? I'd like to see maybe the tech leads and you probably need to nominate another new tech lead as well out to help with that. I mean, I know Luis was starting with the first one, but maybe we re-review that and then go on to, you know, assigning out some of the other use cases. What do you think? Yeah, I mean, that's fine. I think Luis was the tech lead that had put the template together originally. He's obviously not available today, but I don't think, you know, I think he's still on the case. We can follow up with him on Slack. But I think there certainly is the opportunity perhaps for another tech lead, perhaps Shing if you have time, to put together another example based on the template with the document that Luis had started putting together. Yeah, sure. I can take a look and help with that. I mean, it would be good then if we can discuss it at the next call as well. Okay. Next call is it Christmas time? Or is it the new year? The next call will be in the new year. So that would be the 8th of January. Okay. Yeah, I should get that ready by then. Alex, to answer your previous question about any concerns or whatever, I just had a question which is, if I understand that the sort of plan correctly, it is, I just had a very brief look at the minutes. I wasn't actually aware that there were such things for the separate set of working group meetings that happened, it sounds like. So it seems like they were focused on applications, meaning, you know, there's already a decision being made. Well, so they used the word applications, which I think actually meant system components, things like Kafka or, you know, at CD or some kind of thing that needed some kind of storage. And then they tried to figure out, you know, what options you had. And I think in the initial example they used a specific, whatever it was, block store or something to back a specific system component. When we originally spoke about this, I had a slightly different idea in my head and not to say that we have to do this, but I just wanted to bounce it off the group. Which is that users have a more general requirement than, you know, I need at CD or I need, you know, Kafka. They usually have a requirement for, you know, a key value store or a document store or an object store or something like that. And then they have, you know, the implementation of the object store is the one question. Some of them are distributed, some of them are centralized, some of them are, you know, higher durability blah blah blah. And then also those things typically are layered on top of other pieces of storage and so they refer the choices there. So I was sort of imagining that that might be the avenue that we attack it from. What is your actual general requirement? And then what are the various permutations of, you know, higher level and lower level storage systems out there approaches to storage and then maybe some specific examples that are better or worse for these for this particular use case. That makes sense. Yeah. So, so I think we got ourselves tied up in knots last time, because we were, because you're right. I think there is, there is a difference between applications or use cases that consume storage versus some of the things that are actually providing persistence. You're also using other types of storage, right? So, so, so on the one hand, perhaps you have, I don't know, something like Prometheus or something like at CD or something. No, at CD is the wrong example. You have something like Prometheus or something like Kafka for example, which are, which are probably more in the application side of the bucket. And they are consuming some backend storage, which could be a file system, it could be an object store, it could be a key value store, whatever it is, right. And then on the other hand, you have perhaps things like Minio, which is an object store but is probably consuming volumes from somewhere, or perhaps you have a database, which is a persistent layer in its own respect, but it's probably consuming storage again from somewhere. And I think, I think we, we kind of got into a really sort of tight loop debate about this because the example that Louise put together was about Minio and therefore it was sort of, it looked like we were promoting Minio as a storage system and that that was sort of, I think the root of some of the debate. What I really think we, we need to do for this to be usable is to take into consideration the specifics of particular use cases. So, so for example, just just to pick an example if we wanted to say Prometheus say because that's a CNCF project and it's, and it's a use case that needs to consume large amounts of storage. So, so we should be able to say, look, this requires a volume in the file system. You probably are going to have multiple instances of Prometheus. Therefore, you need to figure out how to have volumes on different nodes. The, the, the IO profile of Prometheus requires throughput optimization versus latency optimization, for example, because you have replicas and Prometheus, you probably not particularly focused on the strongest consistency perhaps, you know, and, and you kind of then provide the criteria that you should look for in a storage system, right, so that would allow you to choose storage systems that can provide that functionality. Yeah, so that's sort of what I'm saying, I guess the subtle difference between what I was trying to say and what you're saying is you're focusing on Prometheus. What I'm saying is Prometheus is an example of a, of a metrics collection system. Most of them have similar requirements. They don't have strong consistency guarantees. They do have high throughput requirements, etc, etc. I would have no problem at all using Prometheus as a sort of canonical example and saying, therefore, here's an example of a good way to put in a monitoring system for Prometheus on top of XYZ. But I don't think that we should be to get too carried away with Prometheus. It's sort of one, it sounds like we're promoting Prometheus, which is not really our responsibility. And two, I don't think we would be communicating the generality of the recommendations that we're making, which is that, you know, these kind of monitoring systems typically need these kinds of storage and, and yeah. I, I thought we talked about this though when we went through Louise's thing that that was the changes we were going to make is we were going to be more generic. And that we would then under the exit, we were going to add a section that said like examples of this use case and there we would provide things like Prometheus. So we were going to generalize out the use cases, because we all agreed that it shouldn't start off with like Minio on this blah, blah, blah. And then I thought we already went through this. So I guess I'm confused. You might be right. It just sounded like it was what I just thought was different than what Alex described we were going to do. So I wanted to just clarify that. So, so I think we're confused because we probably didn't mail the debate last time. I think you're right, we should, we should start with the generic. And then I think what we agreed was that we would do the generic, and we would have some examples of what that generic use case covered. I would like, and I'm kind of open to this, but I would like to kind of go one step further. So if if you imagine this to be a directory structure in a repo, I would love to have the generic, but I will also love that the general project owners that for that category are able to write a more specific example that defines best practice for that specific example to I would, I would love it if it would evolve into that eventually you know so for example. Yeah, so for example, you know if the generic use case was like, you know, log monitoring and these are the things that you would like to do. It would also be awesome and then if we go one step further and say, Well, actually, if you're doing Prometheus. Yes, the file system optimized for throughput is important, but you should look for a file system that can handle, I don't know, these type of block sizes or these type of file sizes or whatever else, you know, because they're they're optimizing for some specific things that are specific to that to that project or the use case. Yeah, and I can imagine, you know, Prometheus on a on a five node cluster might look different than Prometheus on a 50,000 node cluster. We could have two, you know, different case studies for those two extremes of that. That sounds fantastic. So I think then you need to do is perhaps as Aaron pointed out earlier, perhaps start sort of shouting the stuff out to to the right and that seems to imply, you know, creating that directory structure that you mentioned, perhaps starting with the, you know, not the leaves of that directory structure but the the trunks the big, the big use cases figure out what there's our relational database to then restore, you know, monitoring system document store, whatever, whatever those things look like, at least, you know, dropped out that thing and then start, you know, electing perhaps a tech lead for each one or something like that. So that's, that's a very good point. That's a very good point. Shall we shall we let me have a note to the minutes for that. So list the trunks for the use cases. What I'll do is I'll, I'll share at a Google doc after this to the team and maybe we can start brainstorming the things that we that we want for those general use cases. Awesome. Sounds brilliant. All right. That's fantastic. So those were the main things we had in the agenda. Amy, did you have anything from the CNC F specifically, if you're still on, I think if you're talking you probably meet it. I'm going to try a different mic. Okay. Cool. It's a different mic. It's fine. Good morning. It's beautiful. The other question that was around Amsterdam and if we want to be able to do a storage day there. Yes. That was it. That's a good point. So, I I have a suggestion, if I may. I found it rather fascinating the giant swing in focus and like I went to see an estate and it was like very customer focused very use case focus, you know, what people are seeing what vendors are doing and then I go to the cube storage sake and and we're very like high level design and I understand they have different purposes but I wish we could find a way to be able to kind of meld those two together where we get to hear from community and customers what's missing and what's needed compared to what we feel like we're driving in the in the SIG in the Kubernetes SIG particularly just a suggestion. I don't know if that can happen, but I just I'm afraid that we won't have enough time even for the SIG storage face to face that one day. We couldn't really finish discussing all the topics we want to talk about so if we combine them together then we'll be even having less time time for those type of discussion. So I think we do need to have multiple events or more time I think. So, so let's let's look at it slightly differently. I think that there are two things that need to come together for these events one is who's organizing it and to who the target audience is for the last three coupons we had set up this this cloud native storage day. And this was largely I guess, sponsored driven because when we set up the first cloud native storage day it was probably the first one of the first co-located events and we had a 400 people waiting list and that kind of then spurred on all the sort of co-located days that started up in Barcelona and then the explosion that happened in in San Diego because I think there were 34 or something different events, which was kind of nuts. But so, so we're going to go ahead, you know, the sponsors who sponsored the last three are kind of getting together and I will be going ahead and probably sponsoring another cloud native storage day too. And that focus is is all about sort of the practical implementations of cloud native storage. So we tend to get end users together discuss actual use cases discuss day two problems discuss, you know, various implementation details and examples and demos and a variety of other things. And that's kind of a mix between, you know, what the sponsors provide and what the, what the end users provide. So, so it's a very pragmatic, you know, how to type of session, as Aaron mentioned. The Cube, the Cube SIG face-to-face meetings obviously all about, well, the technical design and specking and scoping of features and things like that. And is very, very developer focused. And the question therefore is, you know, what role, if any, do we want the CNCF SIG to have in organizing something? Is there an appetite to organize something? And if so, who would be who would be the target audience? Because the question mark I have is, you know, we're kind of neither specifically technology project focused, nor are we specifically end user focused. And I don't want to sort of create logistical processes for the sake of creating logistical nightmares. So I guess my thinking about that this is also how much work one of these things is going to be to be able to move it over to the SIG. Whereas we've already got kind of like the cloud native like security day storage day just happening on its own and figuring out ways to be able to have this group and participate in that without taking on all the heavy lift. Yeah, well, this is kind of what I mean. You know, I was chairing the content committee for the cloud native storage day and that's a lot of work. And, you know, we already have like a lot of cooks in that particular kitchen and it's like herding cats sometimes. Not to mention that these deadlines start pretty early in January. Well, actually, you know, come to think of it, the deadlines have already passed, right? So the deadline for registering contracts for these COLA events was December the fourth, I think. Yes, yes, that was previously. I mean, we work to be able to actually have some flexibility if the SIGs want to be able to participate directly, which is why we're having this conversation. Yeah. So, Alex, I noticed that this time in the CIS day, there was no community session where previously we do have like a CSI session. And I see there are discussions to whether have a CNCF 36 session or a CSI session, but then it got dropped. Probably there are just too many contents already, I guess. Yeah, so we had a lot of content and we decided to drop the CSI session. So the last, the previous two times we had a CSI session, this time we decided to drop it because a CSI has become a lot more well understood. B, we kind of wanted to fit in more end user content and C, there were already a number of CSI related sessions in some different KubeCon talks and in the Kubernetes SIG sessions during KubeCon itself. So we kind of felt there wasn't a huge amount of benefits of forcing it in there as well. Yeah, and also because all the developers are in the other location, right? Yeah. It's not in the same hotel, so that's also a challenge to travel if you want to go to both. It's kind of hard. Yeah, indeed. I mean, poor Aaron was jumping. Okay, she went to both. Yeah, it's kind of hard. I wonder if it's beneficial for CNCF to sponsor like a customer feedback session to SIGS, like in this case I was thinking about this, you know, the Kubernetes SIG storage. So this way we can get some feedback. That's a way for developers and customers to be together. So it doesn't have to be like a whole day, but like an hour or something. We did an end user panel. Oh, okay. We did a maintainer's panel over at the end user partner day and planning on doing that again. So happy to be able to take input around that. Okay. Ooh, that actually would be, that might be particularly useful with, we've been trying to get end user feedback for a while with sort of limited success because even though we've, we have put a survey together, the end user sessions weren't particularly productive. But if we, if we could get us, if the SIG could get a slot at the end user session to talk about the work that we've been doing and to maybe gather any feedback or information on what they would like next. That would be super useful. Yeah, happy to be able to take that. Yeah. Oh, you know what I've seen work fairly well. I'm a program chair of the scale conference and open source conference in the US that draws say 4000 people. And we nominally called this thing a Kubernetes user birds of a feather, but then the crowd that showed up about 60 divided up into categories and it turned out 40% of them wanted to talk about storage. And that was actually a fascinating conversation of end users, helping each other talking about common problems. And then if you're not in that situation of being an end user you could lurk or contribute as you chose. But that birds of a feather at the scale conference actually drew a fairly large audience. And it was like at the end of the day so it wasn't competing with people wanting to go to talks. But that's another format other than a panel where you have to find, you know, unidirectional speakers. And I think the interaction of a birds of a feather where you at this point I'd say there ought to be enough. Kubernetes users some in production some thinking about getting there that the users themselves could drive just random conversations and have it work out pretty well. How long is that bird of feather session. Well it's up to us I mean we'd have to get it on the agenda. I'd suggest an hour would be appropriate and maybe 30 minutes not enough. Really what you do when you open these is you you go around and everybody does a one minute intro and that alone is going to gobble up 1520 minutes. But without some context of who's, you know, coming from where I think it doesn't work as well. And that introductions breaks the ice and gets people talking amongst each other so I'm thinking an hour. And then I think what you're likely to have if it worked well is after your hours up, nothing keeps people from self organizing, going off for, you know, a meal or a beverage, and continuing on if they found it interesting. I think that that is a fantastic idea. Amy I don't know if we can. I will start asking about where we can put that stuff because that is a very very nice in between. We'll see what happens. And also it's probably encouraged more people to join the same as well. Not only that here's another just brainstorm, but we had a few of these go down at cube con San Diego during lunch kind of unofficial self organized, put a couple signs out on a couple tables in the general lunch area and self assemble. And it's a little less organized that I think the only way those actually were promoted were speakers announcing it during a session saying hey we're going to have this event during lunch and look for the signs. And it's a little less formal but that might work as well. Yeah, I attended a few of those and I found them very useful. I mean, quite often people are wandering around looking for someone they recognize to talk to have lunch. And it's great to just have a big sign saying, you know, if you're interested in topic XYZ come and sit at this table and you'll have someone to talk to. Effectively, I think it's turned out to be like that birds of a feather but the table size means you're taking random chances that this group of six or eight are going to be interesting conversations. Sure. I mean, you kind of take those random chances without the signs too. That sounds like a really great, all of those sound like a really great ideas. I mean, I like the idea for a sloth in the end user session, a bird of a feather session sounds brilliant too. And maybe we can get some volunteers from the sick to to partake in some of those lunch sessions as well. Yeah, I think what if we're going to do it, we should self identify some people. We don't want a 100% end users and somebody should be a moderator. But so maybe we nominate some people who are going to go there to be organizers, but that role is really just to promote talks amongst the users, in my opinion. Good idea. And this time we'll have the logo to these right Amy. Yeah, we might be able to get hoodies so yeah. All right. Okay, I've got notes to be able to talk about birds of feather and the end user community and we'll see what else happens. Brilliant. All right. Okay. I think in that case we're, we're done then. One last comment on that stuff, Alex. Do we, I mean, it sounded like we were moving towards almost like a co sponsorship between the CNC of storage SIG and the cloud native storage day or some deeper involvement. Did we decide we're going to do that and I mean, could like officially endorse it or or at least help, you know, choosing, choosing the topics. I don't know what form it might take. Doesn't make sense to do it at all. Well, that is my question. So the CNS storage day will probably happen on its own, whether or not the SIG is involved. The question is if the SIG is involved, what role would they take because the CNCF is endorsing it. I mean, it obviously is a good thing. I don't know if that actually translates to the CNCF helps with the sponsorship or anything. But because these these things are actually pretty pricey to to set up. But the sort of my my question is what what do we think the SIG could contribute to to to that storage day, because actually, as it happens, a lot of the SIG members do already participate in the cloud native storage in some form or in some form or another. We can just leave it at that then. I just wanted to clarify what we had decided. So we've decided to just do nothing. No formal. I'm not saying that I'm not saying that we should decide to do nothing. But I think if there's something we think we should do, I'm open to discussion. But I don't think we should say that we're going to do something unless we specifically know what we want to do. Yeah. Well, well, you know, brainstorm can dump them on the on the agenda for discussion next time. So one would be sponsorship that it is formally sponsored by this SIG to whatever extent we have access to CNCF budget. The other one is to provide speakers if those are needed. Yep. And the third one would be to, you know, assist, you know, so we could people here that tech leads or whatever could chair panels or do whatever might be useful. And they would actually be, you know, in their official capacity as tech lead or chairperson of the CNCF storage SIG, maybe they do that anyway and they just maybe that much I don't know. And the third one could be organizing, you know, helping with the organization. So choosing, you know, maybe adding some value to the content somehow, because we are supposedly the experts in this field. As you say, maybe the people, maybe the individuals who would do that are doing that anyway, in which case, maybe it doesn't make any difference. All right, no, that's all really good. You know what, I'll take this to the to the planning for storage day guys and raise it. Yeah. Yeah, I actually I think that on that level I think that makes sense. Yeah, thanks for that. Did anybody have anything else to raise. Otherwise, I think we're done a couple of minutes early. Great. Thanks. All right. Thanks. All right. Bye guys.