 All right. Good morning everybody. Thanks for joining. We'll give it a few minutes for more to join and then we'll kick it off with the agenda. Hey, Kiran, are you out there? Hi, Clinton. Yes, I'm here. Are you going to be presenting for Open EBS this morning? Yes, Clinton, I and Jeffrey will share the slides. They probably take around 20 to 25 minutes. I will kick it off and then hand it over to Jeffrey for some of the slides. OK, sounds good. We're going to time box it so we want to make sure that we get through the slides by about 8.25 and then leave a few minutes for questions so that we can get into the next agenda item at 8.30. Sounds good. Yeah, thank you. Clinton, can you see my screen? I've just shared it. Yeah, I think you're in good shape there. OK. Good morning, everybody. We'll kick it off in about two minutes. All right, this looks pretty good. We have about 20 people. It should be about average for the group. So thanks, everybody, for joining us this morning. We're continuing this bi-week meeting with a presentation from Open EBS. So trying to share amongst the storage community all the different interesting projects and things that are going on and how they relate to Cloud Native. So there's two things on the agenda this morning. One is this presentation. And then the second is to discuss the SWG presence at KubeCon in Copenhagen. We've actually secured a few sessions there. And wanted to open up for discussion for everybody to figure out what we all want to do and how we can work together to present some topics to the audience at the conference. So we'll do that at 8.30. But for now, I'm going to hand it over to Kiran and to Jeffrey to present on Open EBS. Thank you, Clinton. Hello, everyone. I am Kiran Moba. I work at Maya Data. One of the maintenance of the Open EBS project, so Jeffrey and me will give a brief introduction into the Open EBS. Just to give a quick snapshot of the background of Open EBS, it was started by Maya Data in the early 2017. It's still under active development phase. Right now we are working on this 0.6 release. What was interesting for us is people were able to resonate with the idea and then in the Slack channel of Open EBS. We've seen people say that they're already using it, and some people even claiming that they've put it on production. There's been a lot of uptick in the community activity. So Open EBS is tightly related to Kubernetes, tightly integrated into Kubernetes. So most of my time these days is on the Open EBS Slack channel or sometimes the issues spill over into the Kubernetes. So I'm finding out in the Kubernetes users channel as well. Kind of understand what Open EBS brings to the table. It's similar to Calico and VU if you consider that as an analogy. Just like how they provide network services by containerizing the network capabilities and then use the underlying network infrastructure of the nodes itself. Open EBS also containerizes the storage capabilities and provides storage service to other workloads, at the same time using the storage in the hardware attached to the nodes itself. So the main agenda for this meeting is to show you how Open EBS fits into the storage landscape and then also walk you through a few slides that show how it works at a very high level. And then talk about some of the problems that we are working on at Open EBS. We think that these problems are common to any of the other storage solutions that are being worked on with the container environments. We'd like to share that and then also accept any collaborations that we can get out of this meeting. So Myrita is the company behind it. You must have seen this in the last platform that's where the company was launched. The primary goal of Myrita is to work on the problems around data management with the focus on simplicity with respect to the managing the storage. To understand Open EBS, so I kind of broadly classify the storage solutions out there into these different categories. And I'm just thinking most in terms of Kubernetes. So most of the terms that I use are related to Kubernetes. So the different possession volume categories that we have out there can be kind of grouped into three categories. The first category or the most commonly used category is the network attached storage. Here, the storage capabilities are coming out of the Kubernetes cluster over the network. This external storage servers are something could be like our standard storage vendors or it could be even, let's say, EBS or GPD. They all fall into this category. In fact, me, Jeffrey and team at Myrita, we come from the background of developing one such storage server in our past lives or actually multiple of them in the last decade or so. In the software defined space and also containerizing the storage itself. So we've been using previous details for some time to containerize the storage there. So the other thing that's been making some, or like, kind of finding it way through is the direct attached storage. Lot of enhancements going on in there as well for the simplicity of deployment itself. But this kind of helps those applications that can take care of some of the replication and high availability kind of requirements. So something in between these two is what we call as container-attached storage. There have been different names given to this category but we call it as container-attached storage. So here, the storage capabilities themselves are containerized. So we call it as container-attached because the containers are serving the data here. They make use of the local storage attached to the Kubernetes and then expose the data back to the stateful workloads. While the capabilities like replication, snapshots, encryption, et cetera, are taken care by the storage containers. So the cool thing about this container-attached storage is they are themselves for containers which can be run as workloads in Kubernetes which kind of removes the management or like delegates the manageable capabilities. Like any other workloads to Kubernetes, for example, installation upgrade, monitoring capability can be used by the same tools that you use to manage your standard workloads. The containers themselves specifically deal with capabilities of storage management or the disk management and the data protection and high availability aspects. Just covered that part there. So to kind of get a glimpse, let's see how OpenEBS is used. Could I ask you a quick question? Sure. So CAS is already kind of an established acronym for content addressable storage. Is there a reason why you didn't go with software-defined storage? Why did you choose container-attached storage? Okay, so. Right. So the container-attached really comes from the source of the storage. So looking at network-attached storage that data is serving over the network, direct-attached storage by the disks directly attached and container-attached is probably to say data is being served from containers. Yeah, that's a good question. I didn't know that there was already an established term called CAS. I'll take that as a feedback. Thank you. Thanks. So looking at the OpenEBS volumes in use, so it's as simple as starting with any Kubernetes cluster that you have with one or more nodes with some kind of storage attached to it. Either it could be like your host disk itself or maybe like additional disks. So OpenEBS uses Iskasi as a way to connect to the storage containers. So Iskasi initiator is one of the prerequisites of the only prerequisites that we need to have on the nodes. And then we can, or the cluster administrator can configure where the data is stored, whether on a post directory or whether on the external block device using CRDs, which are called storage pools here and then tied into the storage classes. So that's pretty much the setup part of it. Then you get into the regular workflow of a PVC referring to a storage class. And then the workflow starts by kicking in the OpenEBS dynamic provisioner that will spawn in a storage container or in this case, let's say it's a Iskasi target. This is standard Kubernetes deployment with the service attached to that one. The service IP is the one that we use in the Iskasi IQN. And then depending on the policy attached to this particular volume, that could be one of more replicas. The target takes care of synchronously replicating the data to all these replicas. And then we create an Iskasi PV out of it and hand it over to the Kubelet, which takes care of attaching it to the pod and then running the workload. So the next few slides are taking from a live example, the different Kubernetes samples that get generated. So this is the PV, the object where it's a... The PV is a storage class as OpenEBS. And the PV spec... Is anyone else hearing that same problem with his audio? Yeah, yeah. Yeah, yeah, I had out there for quite a while. Hey, Akira? Yeah? Akira, are you out there? I can hear you, Clinton, can you hear me? Yeah, you were just cutting out. So I think when you started talking to this slide, you started cutting out a little bit. So it sounds like you're a bandwidth or something like that's a bit low, so we're not hearing your voice at times. Okay, let me see if I can switch to some other speaker. Murat, can you hear... I don't know if it's a speaker. I wonder if... Are you driving the slides from your computer? Yes, I am. I wonder if someone else in your team could drive the slides and maybe you can just use your bandwidth for speaking. I don't know if that's the problem or not, but we couldn't really make out anything you were saying there for a minute. Okay. You sound okay now, Kiran. Yeah. Should I back up a couple of slides? No, I think you're good on that slide. Let's give it a shot for right now. And if he starts getting interrupted again, well, I'll let you now want to figure out how to drive the slides in a different way. Thank you. Sorry about that. Okay, so the next slide, as I was saying, is all walking through the computer's object, so I'll quickly run through. Yeah, hey, Kiran. Hey, Kiran, you're cutting out. So the service IP is... Yeah. Yeah, you're cutting out. So let's try this. I think that everybody has the slides in the meeting notes. If not, I will post it to the channel right now. Let's try to see if you stop sharing and see if your voice gets better, and then everybody can drive the slides themselves to follow if that works. Clint, could you share the slides? Yeah, I'm gonna share those in the chat right now. Okay, the link is in the chat for the slides, so everybody can follow along. What slide number are we on, Kiran? Seven. Okay. Or is an alternative I can share from my computer and Kiran talk over? Yeah, you can give that a shot. That works too. For anybody else, we're starting on slide, so. Okay, Kiran, do you wanna give it another shot? Sure, so I'll go ahead with the slide seven. So slide seven through the slide 11 are really talking about the ISCSI, the Kubernetes elements that get generated as part of launching a new volume. So the first one is an OpenEBS PV that's on slide seven. And then the IQN portal IP is something that's coming from an ISCSI target service that's on slide eight. And this service is really tied into a deployment file that launches the OpenEBS storage controller. So OpenEBS is both looking into the control plan and it also provides containers for running the storage itself. The images are pulled in from the Docker hub and the source code for this is available on OpenEBS GY as well. The replication also comes from the same images with a different flag and you use again the Kubernetes deployment, which is on slide 10, the replication factor is coming from the deployment itself and we use for the anti-affinity node tolerations, et cetera, to kind of pin the replicas to the nodes where the storage is available and making sure the replicas are on different nodes, right? And the other thing about the replica is we use the volumes itself to kind of show or link where the storage has to be persisted. Depending on the policy, it could be like a local host itself, right? On slide 12, to kind of sum it up, the transparency with which the storage is deployed is what's more appealing to the users. So Ryan is one of the tech evangelists at one of the large enterprise companies. His role is primarily to find storage solutions that work with Kubernetes. And he finds that OpenEBS appealing because he doesn't need a separate storage admin to maintain the storage infrastructure and he's currently running it on a different clusters with kind of less nodes. And he's also become a contributor and helping us push the OpenEBS chart into the Kubernetes repository. So then slide number 13, if we run is more like an architecture slide, but these days all the architecture slides are like Kubernetes architecture slides. So we start off with all the components that we depend which come from Kubernetes itself, the primary one being the ETCD. We use all the configuration objects that are required by the OpenEBS control plane as CRDs in the ETCD. And then when we launch the operator, the main things that are launched are the AP server and the provisioner. And one new thing that we are launching is the node bot to deal with the storage management operations on the nodes itself, right? Since these are Kubernetes native components itself, you can use the same constructs like the code dashboard or Grafana or Prometheus to monitor and manage these objects. This is from the cluster admin perspective. And then when a developer or a user tries to run his workloads through the PVC, it launches the OpenEBS volume pods that we kind of walk through in previous slides, right? So that's at a high level, the different components of OpenEBS and how it works. Now talking about where we are focusing on these days, since OpenEBS has been put into use, we are kind of looking at some problems that come in with respect to ISKC-PVs from the kubelet, whether it is running in a kubelet in a container or not as detached the stale mounts, that kind of stuff. So this is where we are kind of focusing more these days to contribute back to the Kubernetes community. And these I think are some general problems that can help other ISKC-based solutions as well. The other thing is volume policies. We just briefly talked about the replica, but I think when it comes to storage, there are a lot of things that we need to track as policies. Could be like a snapshot schedule, RPO maintenance, et cetera. So we're looking at some collaboration in terms of how do we make the volume policies as first class citizens just like storage class and PVC and Kubernetes, open to suggestions and feedback. The third item. Just a question, what engine are you using to write bits to disk? Okay, so that's the GWAR here. And that's kind of also from the OpenEBS repository itself. It's the source of the idea came from the Longhorn. We also have like other engines that are being implemented, which we will talk about it in a bit, Basam, right? Yeah, what's the relationship between Jeeva and Longhorn? So Jeeva was a fork from a Longhorn and then we started making enhancements in terms of exposing the ISKC target on top of it and then kind of hooking it up with the backend storage on the disks. And is the Longhorn project continuing or did you guys fork it because there is kind of major differences or did you, what was the, I'm not sure I understand if Longhorn is still going or not. Yes, so Longhorn is still going on. We need to still kind of fix that part, but to that point, Jeeva is just one storage engine. In the next couple of slides, we will talk about another engine that also comes from OpenEBS. Okay, cool. So I focused primarily on the control plane and hooking into the Kubernetes part and Geoffrey works on the storage engine so he will be able to give more details on that one. So the next one is about the storage management with respect to the node part. So one of the things that we see is, there is some work going on with respect to the local PD but making those persistent storage options available as some kind of a first class objects just like some kind of resource is something that's still missing in the Kubernetes and also how do we dynamically attach and detach to storage engines so that we don't have to restart when we use it as a local PD. That's one of the challenges that we are trying to tackle. How do we make it data center aware or like fault zone aware? I know these are the problems that I think as a storage community, we are trying to grapple with in independent ways. This is something that we think we all as a storage community could also solve together. Some Kubernetes issues that are raised in that regard and then one of the design documents that we are putting together is linked here. With that, I give it up to Jeffrey to kind of touch upon the question that you raised Basam just now and then also walk through the storage engine related changes. Okay. Hello, Paul. Can you guys hear me okay? Yes. Okay, great. So thanks, Kiran. So as mentioned, my name is Jeffrey. Just a real quick introduction. I've been in storage for around 10 years. I was actually at the tipping point of my career when I thought that I wanted to get out of storage. But then containers re-happened. So here I am working on storage. I've done development across the whole stack of storage systems, kernel, user, software-defined and now trying to do, I suppose, the logical extreme of software-defined storage and that is storage for containers and containers. So before we went out and designing the storage system in containers, we first stopped and figured out, okay, so what are the requirements in a containerized environment? So typically, storage developers reason from the bottom up and so we really tried hard to invert that process and when we put the DevOps persona central and reason from the bottom down. And while doing so, we noticed a couple of things and I wanted to go over them real quick. And obviously, one things that immediately show up is the way that we build and deploy and put applications in production has changed a lot over the years. I probably do not have to tell this audience how that works. You probably even know better than I. But it has evolved for sure. So we believe that these typical new application properties allow us to rethink certain aspects and can potentially impact the design of the storage system. So we decided rather quickly to build in yet another scale out storage system or a distributed file system because these systems can be found in the stock Linux kernel today and we did not believe looking at the previous properties like scalability, native application and reliability that that wasn't necessarily a good fit. And also distributed storage is really hard to develop probably even harder to debug in production and so sometimes you actually need special drivers to unleash the full potential of these distributed file systems. So we wanted to try something else. Another thing that we notice is that the hardware side of things really enforce change in the way we do things. Single NVMe devices can do up to 450,000 IOPS and even a lot faster these days already. So we don't really need to scale to achieve higher IOPS is our reasoning. Similar for capacity as microsurfaces typically have a small working set size and when you look at the container attached storage perspective the data sets are relatively small. So I'm going to slide 18 now and we'll get to in a little bit in terms of what we're doing. So as Kiran mentioned the OpenEBS replicas are pluggable and we like to believe that there is no one file system to rule them all. For example a copy on white file system has great properties in general but not so much if you do a relational database that have their own right ahead logging and things like that. Some databases even want raw disk devices and open the disk device with O-Direct and do everything themselves. So one of the file systems that we're working on is the implementation of the DMU engine of ZFS. I'd like to point out that this is not running in kernel but in user space. I will go into the problems that we're facing there and the solutions that we're applying to mitigate that transformation to short of speak but what it allows us to do very quickly next to the properties that ZFS has like end-to-end data integrity encryption and enterprise class quote-unquote storage features like snapshot clones and replication is to do storage... Jeffrey real quick just to make sure we're in check five more minutes and we'll do questions. Yes I have three more slides so I'll be really quick, really quick. Thank you. So we can move persistent workloads across the clouds leveraging the technology of ZFS. So as mentioned we're in user space sorry I'm slight 19 go a little bit too quick now. So performance problem as we move ZFS to user space and unpeel the onion and only grab the transactional layer of it. Linus Torvald is probably well known to everybody made a comment that file system user space are nothing but toys. So when we look at the problems in terms of performance the performance bottlenecks in user space are the context which copy and copy out in a particular DMA transfers and the other aspect is that we again observed is that with current hardware trends the kernel actually becomes a bottleneck so we are kind of reached this impasse where we're saying that file system user space are toys on the other hand kernels are becoming the bottleneck due to these new technologies like hundred GB networks and in the devices and three day cross point. So next slide the solution that we thought up is we completely bypass the kernel altogether run everything in user space and basically put all the devices in a container and we call it the IOC and in the IOC we run specific software that instead of is interrupt driven constantly pulls for completion using Polmo drivers and things like that. So we basically end up with a virtual containerized virtual file system to short of speaking instead of submitting the IO to the kernel you submit the IO to the IOC so the problem then of course that we needed to solve is okay so how do we change this IO path from kernel to the IOC without rewriting all the software because that will definitely not work and the solution for that is that we looked into the host technology that we borrowed from the virtualization space so the IOC among others can expose different interfaces the host is one of them and the replica containers locally on the node connect to this IOC through the Vios protocol using shared memory for read write so that makes it general copy and the event FD to basically kick the other if there is data written to the shared memory buffers unfortunately there was no Virtual IOC library that you could pick they were embedded deeply into BeHive KMU and other hypervisors so we wrote one of our own that's as you can find this in our open source repository and the trick here seems to be that you need to allocate huge pages and pin them and then they become suitable for DMA we're also exploring future work with integration with FDIO or FIDO if you will and in particular the VPP VCL that allows us to do vector packet processing so that the network IO also goes through the IOC final slide to put it in the picture this is basically on the left side this is how it looks between two processes sharing data between themselves through pin share memory I don't think that this is something new other than the fact that we're doing this directly in a container without a hypervisor and the right hand side is a trimmed down picture of what it would look like on a single node so you have the IOC that does 100% pulling then you have the app and the target which Kirin mentioned and we replicate N ways which is all defined in YAML the target writes to the replica the replica applies adaptive pulling because when we really want to go fast we can't afford the context switches to for EPOL so we really do this busy looping if the load is low we switch back to EPOL and then we transform to speak DIO, apply checksums and put the thing on disc snapshots and what have you and then submit DIO back to the physical disc to the V-host layer and then eventually boils down to the IOC so I could not talk any faster than this keeping in mind that my native tongue is not English but with that I am at the final slide and if there are any questions please feel free to ask Thank you so much for that Jeffrey I got a quick question for you so the name OpenEBS I don't think I heard much about EBS in here so how does the name relate to the project at this point? Well so the name was actually based on the fact that it is it relates to EBS so it kind of rings a bell to sort of speak the fact that it's open also speaks for itself the open source to be 100% 100% honest the name was already there before I joined it refers to the fact that it is block storage for one and it has strict ties to obviously how the way the way that we do cloud storage in general it's basically elasticity from block storage comes from that we can spin up containers so we get it that way but yeah a better reason I would have to come back to you for that okay Just a question so did I understand that you are dropping the long horn based Shiva and then going to a new back end is that the plan? Well partially is that we have multiple pluggable back ends for which long horn is just one of them and we believe as I mentioned that different workloads require different type of on-disk formats to sort of speak so we will have multiple and these are just the first two okay and are you planning to support any of the any commercial or other back ends? Like if there I don't know take your commercial one Yes we are obviously well obviously we are very flexible in the sense that we can integrate with others relatively easily this is because we have virtualized the IO stack to sort of speak so for us it doesn't really matter to what we write it could be a physical this was more ended towards local devices direct attached storage concept but we could just as easily write to an RBD volume from CEP or from Gluster or what have you And so is the role of OpenEBS as a if you're not tied to a specific back end is the role of OpenEBS essentially as a orchestrator of storage it certainly does a lot of orchestration of the storage but eventually it doesn't really matter what you do eventually you need to write the data to a disk right and we give you the freedom to choose what disk that is if you want to write it to a local disk then you can use CSTOR if you insist on writing it to a Gluster volume or an RBD volume we will not stand in your way that's basically the freedom that we provide augmenting obviously the capabilities with snapshots and cloning to that local volume right it's just a block device okay got any other questions out there so regarding the CNCF like foundation as an open source project are you guys interested in just growing community around OpenEBS and submitting it as a project to the foundation like how do you see the future of the project in regards to the ecosystem well actually the reason for us obviously is to have cross-pollination with other open source projects in particular and community growth I think in all honesty I don't need this in any way to come across arrogant but we kind of have this organic growth so maybe Kiran has some other things that motivate him at a personal level but to tie in with the other open source projects is the most dominant reason for us or at least for me maybe Kiran has an additional I think you said it right Jeffrey Clinton so the interest is to basically gather the community work on some of the common problems it could be on this project itself or directly on the Kubernetes itself and yes we playing with the idea whether to submit to CNCF or not and it really depends on the community's interest and the community feels that this should be submitted to CNCF got it okay great anybody else have questions so this is Steve what that wasn't like super clear for me but I just first want to say I'm glad to see you guys out here I've always been kind of wondering who you guys were and what you were about so I'm just very interested to see the presentation welcome and so just to go back to the CNCF thing would it be fair to summarize that you're going to poll your community and if your community thinks that becoming a CNCF project is in the project's best interest and that's the path you'll go but if not then you'll just keep doing your own thing is that right so it's not just the open EBS community but the community that we have on this channel as well so for example 6 storage and the CNCF group as well if the idea is appealing to more people here we definitely with the idea of pushing this into the sandbox but I want to hear comments from the people on this call Mr. okay I think we can definitely follow up with an email thread that's fair and I apologize sincerely for going so fast in particular over this whole IOC concept and be host to how that ties in but time was scarce so I really did my best to go as quickly as possible but anybody feel free to drop me an email or whatever and ask questions and you know and I thought it was great Jeffrey I'm sorry for pushing you guys on time we do have this recording so if anybody wants to replay it a couple of times to hear it all the main link is posted on the CNCF storage working group GitHub page okay thank you great okay aside from starting a thread for any extra questions or directly contacting the team at Open EBS let's move forward the next item we have to discuss for the day is the sessions that we've secured at KubeCon to discuss to talk about SWG related topics Ben are you out there still yep I'm here cool any preference on how you wanted to proceed here I was thinking about just opening up a discussion you know we have two different public sessions to do we've got one private that we could do optionally I guess I'm just curious to hear everybody's ideas on what they think they should cover so I don't know if you had any way you wanted to cover this no that's exactly what I was thinking as well something I wanted to call out was the Kubernetes storage SIG has one intro session that's going to be at the exact same time that's going to be issue because I know there's overlap in the folks that want to attend wow okay same as KubeCon North America I think that's not ideal one thing I did notice we for storage SIG we only signed up for an intro session not a deep dive and it looks like for the CNCF work group there is both an intro and a deep dive maybe we could offset it such that storage SIG does an intro session during that time slot and the CNCF work group does a deep dive and that way you have two separate sessions that the same set of folks can attend yep let me take that as an action I'm going to go back to the conference team the committee and see if we can reschedule the intro ideally it would be great to have more storage sessions at the conference than less I think so if we could get them to move it that would be cool I agree we definitely shouldn't be overlapping that's not ideal so let me go back as an action on that to talk to them about it cool thanks alright so considering that we got these three sessions maybe we should start with this face to face because I think that is a little bit questionable we secured this at 820 on Wednesday night I think 820 to 940 I'm not sure that timing wise it makes a ton of sense I'm kind of curious to hear what what the team thinks about that whether we should cancel that session or whether we're going to have enough people interested in enough stuff to talk about at that time of night so is this like a session in the QCon EU catalog that there's an 820 PM session? no this isn't in the books this is an internal face to face that we could decide to make public or not it's just a room that's reserved for us at 820 okay so just like the one at QCon North America it's like it's like a place where we can all go and debate excitedly yeah I think that one was published though in the catalog one's not but yeah it could be similar yeah yeah so you're just pulling to see who would turn up yeah I mean if for one would anyone even show up to it at that time and do we is that of interest to spend time face to face for the hour and 20 minutes to talk about stuff 30 PM is pretty darn late and if we have the other two sessions is that going to be sufficient for discussion yeah you know my experience on like these face to face is at least with the Kubernetes story segues like what we do is we get a couple of topics that are just too meaty to we need a high input conversation and then we schedule those for face to faces so and then they're often like they exigent that like we'll make time to discuss them and so I was curious do we as a working group feel like there is some really important topics that we need to talk about in face to face I'm not sure I think that you know the TOC is still figuring out you know I think the guidance for us if you guys heard on the last TOC call the serverless team you know put out their white paper and Alexis was asking the TOC you know what they thought of it and if that's what they want SME views to do and and I feel like short of that guidance to us of like hey go go start working on this white paper go start working on these definitions that we may not have meaty topics quite yet to cover except my thoughts on what about the rest of you I think it will be useful to have a couple of topics and then decide what we what we want to cover in the face to face so maybe we can have that discussion first so I agree with Steve on that sounds like you'd go to a song that's what I'm hearing if we have a couple of topics we want to cover and then I would definitely go one topic that I think is a high throughput conversation is like getting to the bottom of like I don't think we actually closed on the whole when we say CNCF storage work group what are we referring to and I think we could have a debate on like where the line is between application persistence and storage and what exactly is the scope that we're going to be tackling in this work group right I wonder if we could get Alexis or multiple members of the TOC to come talk to us and discuss that exact topic that would be useful then what do you think about that yeah I think it's very possible I think Brian Grant would probably be interested and I think we might better get Alexis as well so I'll write that down to you so I think you're asking hey what's the SWG and then I'll write down another action to talk with Alexis and Brian about joining yeah because I mean I think if I just back up like I know we said to the the TOC like look we're going to help like disambiguate the storage landscape and perhaps naively I thought that was kind of a simple thing because I was just trying to disambiguate what we had there right and then what it did is it surfaced up this broader conversation of like what is storage in the context of Cloud Navy the you know and then and I was naive about it because essentially we haven't had this problem in the Kubernetes storage SIG although it could just as easily have manifested there which is you know what is the focus of the SIG and it's the storage primitives so I assumed that was the same thing here but I think as we saw there's varying opinions on you know that and I think regardless of like the taxonomy we've got to figure out it like what level of the taxonomy is our scope because we can't fulfill on all the stuff we promised to the TOC around you know writing this landscape white paper and like you know doing the rest of the stuff until it's in the critical path I think there's you know multiple work streams that are kind of going on that impact that as well you know the TOC is considering reconsidering the definition in the Charter of Cloud Native which I think impacts all of the projects and the positioning and the work groups and how they think about things so I feel like there's some fundamental changes that are happening which essentially we need to build upon and the definition of Cloud Native Storage and all that stuff like comes from that work so I'd be really interested to hear from like Alexis and team in KubeCon in three months where they're at with that and then what their thoughts are on the SWG and what their thoughts are on the scope of the SWG exactly as you're saying Steve okay so I'm good with that anybody else have any comments there or things that they think should be covered at that face-to-face