 Hi Ardalan. Can you hear me? Hi Erin, how are you? I'm good, how are you? You're well, thanks. It's been a while. Jennifer today, people a little bit of time to get here. I'm going to give everyone two more minutes to join. It doesn't look like we have very many people today. Hi Lois. All right, it's five past. Let's go ahead and get started. So I put in the chat, hopefully, I don't know if Zoom allows you to see the chat after you've joined or not. I'll go ahead and repaste just to be clear. So today we have just three items. The first one is the Dataset Lifecycle Framework. Yeah, Eunice, I believe you're joining to talk about that. The project went through a sandbox review on the TOC yesterday and they had some questions about how it differentiates from the cozy cap. So I wanted to start just with that discussion, if we could, please. So to that context, I shared the frequently asked questions. I just compiled it today because the document is still lacking and it's a bit difficult to digest what is exactly the framework trying to accomplish. And the comments were fair, right, about, you know, not being very clear on what is adding to the ecosystem and how does it compare with the cozy or with the other CSIs. So if you have, so I can just share the screen for the wiki or you can just. Yeah, that'd be great. Please do. So can you see my screen? Yes. Okay, so yes. So I will just go through everything because it's just a few questions, right? So what does the framework do exactly, right? So it brings one new custom resource definition, right, the Dataset. So basically it's a pointer to an existing data source and the current implementations is both S3 and NFS. And so yeah, is that just a sure thing? No. So basically what we're doing is that we're trying to map, not we're trying to map, we are mapping every Dataset that you create with one pbc that the users can directly mount into their pods, right? And the logic is implemented as a normal Kubernetes operator. Now, what is the motivation for this work? Why we started looking at that, right? So when container storage interface was introduced, right, more and more storage providers were available on Kubernetes environments, right? It's just that from our perspective, we feel that the barrier for non-experienced, non-powered users of Kubernetes, right, the barrier is a bit high to leverage the available CSI plugins, right? And gain access to the remote data and sources on their workloads. So that's what we're trying to enhance. We're trying to enhance the user experience mostly of data access in Kubernetes. So we're bringing the high level of abstraction, the Dataset, and we take care of all the necessary work about invoking the appropriate CSI plugin, configuring, provisioning, and giving in the end the pbc for the end users to use, right? Of course, we're not looking to replace CSI, right? If you go through our framework, right, we have implementations of CSI plugins that are standalone, right? So you can take this part of the code and use it. So we have CSI S3 and the CSI NFS implementations that are actually open source and I will talk about what we did there. So our aspiration, right, is to be like a meta framework, right, for CSI plugins and the comparison that I like to make is like the same way Kubeflow, you know, makes machine learning frameworks accessible in the same fashion we just want to make CSI plugins and pbc's accessible to Kubernetes environments. So to the cozy proposal, right? So, of course, we're not competing with the cozy proposal and we're not currently, right, aiming to have this functionality, you know, rewritten as part of our framework, right? So when we started the project almost a year ago, right, the only CSI plugin that we were aware of was the CSI S3 that I'm pointing in here and actually we have four and we maintain because there were some dependencies with the side cars and all this stuff. We are updating this as is in our in our repo, right? So now in the future, right, when cozy interface becomes part of Kubernetes, of course, we'll stop maintaining our fourth version of the CSI S3, right, and directly invoke cozy for creating a pbc for buckets in cloud object store. cozy also aims to manage the full life cycle of a bucket provisioning, configuring access, which we don't, which is actually beyond our scope, right? And the buckets and the S3 is just part of what we want to support as type of data sets, right? And an additional some additional benefits that are on the roadmap and we have some initial implementations we feel that it's after you introduce that concept of a data set as a high level abstraction, then you can build also high level orchestration, right? So I think we can achieve improvements in terms of performance. So we have you can have we try to present a pluggable casting interface and we have an example implementation of how this would work. So it will be completely transparent to the user and they can provision castes depending on the type of data sets without the user explicitly, specifying cast or configuring the cast on the row. And also we feel there might be interest on the security aspect, because imagine that we could have a common layer of access management for credentials of the different type of data sources, whether you have, you know, your normal S3 credentials like secret access key and the access key API, and the same fashion you can have username password, all part of the same access management layer. And we believe that we there are there are there is some interest. So I would like to point out and give a shout out to the people who have embraced the framework, even in these very early states, the European Bioinformatics Institute, and David specifically are running a POC with BLF and Kubeflow on their cloud infrastructure. So basically they're using pipelines and S3, the 1000 genomes data are on S3 buckets. And they're rewriting their pipelines to with a data set convention because the S3 credentials are before the left were repeated and you know, plug everywhere like environmental variables. Instead with our frame with our frame, they feel it's more convenient for the user to digest and write their pipelines. There is interest on the open data hub. And you can see a relevant issue that there is interest in integrating BLF directly into open data hub. And of course, there's party terms proposal, which is actually very close to the data set specification that we are supporting in our code. And if you look in their, in their code, the elect is actually forked. And it's been under evaluation whether you know, it can support the implementation. Right. So we make a pause right now and, you know, take up any questions or comments that you might have. I just had one question. So I thought the purpose of using the PVC though was to leverage the way that we mount volumes to keep that inherent functionality for the data sets. Switching to cozy, it's not going to be exactly the same, but that you regardless, you're still the idea is still you're wanting to basically provide an easy accessible way to a specific data set. So it's almost like pre-populating a bucket basically and allowing a pod point directly. I need to start there a bit more the cozy proposal, but I thought also it was wasn't sure that it was part of, you know, creating a PVC, but you know, if if it's more integrated, the more it's integrated to the Kubernetes environment, the better for us. Right. So we won't have, we don't have to do any new types of orchestration on our own. Right. The PVC. So imagine that there's a one-to-one mapping, right. One data set, one PVC. If we are thinking the data set to be like a user facing thing, right. So the user is aware of data sets and in their posts, they just use a PVC, the configured PVC from, from the framework, right. And also we're envisioning scenarios where there would be another, another provider, let's say, creating the data set pointers, okay. So it's a data set object. There would be another persona creating in the cluster, the data sets and would be the other persona, a simple user, simple, you know, a user who just wants to launch pods and launch workloads that way, mount in their pods without, without, you know, configuring, finding pvcs and all this stuff. We are adding an admission controller to inject those pvcs in the pods with labels. But this is an additional feature. It will, the PVC would work on its own as a normal PVC in Kubernetes, right. And that's our goal, not to bring, not, not to replace pvcs, not to replace CSI, but instead have a more user-friendly interface. Maybe, you know, even configuring it for, for the users who don't want to be bothered with, you know, provisioning and creating the configuration for their pvcs. Okay. This is very useful. So thank you for putting together this FAQ. I think that will help clarify some of the questions that the TOC had. I'm not sure and it doesn't look like Amy's on what the review cycle is. Maybe it'll be pushed out till October again when they can get back to it, but I'll find out and I'll, I'll let you know. So the, the other thing I would say is, you know, we were striving to get more feedback. So what I'm trying to understand the new process is a bit not clear to me because I was starting to be put on a pull request, then it was a Google form and it was a bit kind of hard to keep track on where the review was happening. And I didn't get a chance to explain a bit more. Well, I understand it should be part of the framework and the documentation, but yeah, anything, anything that I can answer or give a better explanation or demo I would be happy to. Right. So it's perfectly fine that you find the new process a little confusing because it's only been since August and I don't think it's ironed out yet. So the new process, the idea was that they were going to try to simplify the way that projects got into sandbox and not require a presentation. The idea was that the TOC could look over the questionnaire that was filled out and then if they had additional information, they would kick it back to the SIG as they did here. And then we would provide that information. So yeah, you're not required to do a presentation. You already came on the SIG, we recorded that, we provided that information. That communication is still being ironed out. So I think you've provided everything you need. If not, I'll reach back out to you and let you know. Okay, great. Thanks. Yeah, thanks. I'll send this over to the TOC, find out when their next meeting is and I'll get back to you then. Great. Thank you for this. All right, moving down the list. Kieran, I believe you had some updates on the licensing questions we had from the last time we talked about OpenEBS. Yes, I have updated the agenda doc with the information I'm trying to put together. The action item was to list all the OpenEBS top-level repositories and what are the dependencies those repositories have on other projects. I can probably share my screen and quickly walk through that. That's okay. You're on mute, Kieran. Thank you. I think the question was around the CS Tor engine, right, that license. Okay, yeah. So go ahead and share your screen and we'll walk through that. So what I hope you can see my screen now. Along with the CS Tor, I kind of updated for the remaining repositories also. So maybe I, you know, since CS Tor was the first one that had a lot of open questions, I'll cover that and then we can go back to the other ones. All right. So the main concern with the CS Tor is it's a, it kind of depends on the ZFS and ZFS itself is a CDDL licensed project. So what OpenEBS did was for the OpenEBS ZFS project, which is actually a kernel, ZFS, you know, you can kind of build kernel module with that and ported that to work for running it in user space. So the OpenEBS CS Tor, which is a fork of OpenEBS ZFS is a modifications for making it work on user space. And then the actual functionality of how OpenEBS uses that framework or uses the ZFS for storing the data and the replication and high availability features that were added on top of it. They're all part of the OpenEBS CS Tor and OpenEBS ISTGT repose. These themselves, you know, since Lipsy Store is completely written by OpenEBS authors, that being Apache is not a problem. Now, the, you know, prior to the last call, the way the code was being built was the OpenEBS CS Tor was actually pulling in the changes from Lipsy Store and building that binary that was kind of highlighted as an issue. So now we turned around that. So Lipsy Store is the one that actually contains the main call, if you will, that instantiates the binary and it uses the OpenEBS CS Tor as a library, right? Just like any other project would use any other dependencies. So that's where it is at. Now, still keeping it open for discussion and trying to understand if this is okay or anything further needs to be done. I'll leave it at that. So yeah, I think this helps clarify how, you know, how you're using it, how it's being built differently. I think it addresses the questions. I would need to probably run this by Alex and Quentin. I think we have to have consensus from the leads before we move forward. And then it would of course still go through the due diligence as it was normally. So, but before that, does anyone have any questions around this or concerns that they want to bring up? Off the cuff, it seems to satisfy the concerns we had. But let me talk with Alex and Quentin and then get back to you, Kieran. Does that work? Yeah, that's perfect. Okay. Thank you. And I can't remember who was, was Saad doing the due diligence for OpenEBS for you? Okay. Last time when we had the presentation, I think this was the first thing that we had to get across before assigning the reviewer. I don't think anybody's assigned yet. Okay. All right. Sorry. I'm just taking notes and I'll update the notes after the call. I'm writing them down so I can listen. All right. Perfect. Thank you for that. I appreciate it. And you included this link in the agenda, correct? So we can get back. All right. Thanks. Okay. The last item we had was Prevega. We need, so Justin Cormack from the TOC offered yesterday the day before to run the due diligence, but we also need a tech lead from the SIG. So is there any volunteers? Volunteers for what? Exactly. Sorry, Luis, I'm on mute again. To work with Justin and Casey, he has questions on the due diligence for Prevega. I'm not very familiar with it myself. Okay. All right. Not all the tech leads are on the call today, so I'll just send out a separate note to see, you know, who's most familiar and has the time to be able to dedicate to that. Actually, it would be maybe nice, maybe at the next meeting if we could go through the due diligence that's process, because I myself do not know it very well. I don't know if many people do. I don't know if that will help. Okay. Yeah. I'll add that as an agenda item for next time. Maybe an expectation too of what the tech leads do to the due diligence. That would be great. Aaron, this is Tom. I would like to draft that process and kind of see it in action. So that Prevega is an interesting technology. If there's a chance for a newbie to kind of watch along and see it go through the paces of coming in, that would be great. Yeah, that'd be awesome. I don't think we have a good process today. I think in the past it's just been whoever has the time and we go through it and we just work together and it's not necessarily repeatable or comprehensive. So absolutely, if you have time to volunteer and want to do that, that would be awesome, Tom. Thank you. All right. That's all I had for the agenda today. Does anyone else have anything that they want to talk about or bring up? All right. Then I'll give everyone a little bit of time back on their calendars. Thank you. Have a great week. Bye, guys. Bye.