 All right. Well, I guess we're live We are sadly still missing our intro video, but you know, hopefully we'll get that in the near future Nothing like a little, you know, a couple of technical difficulties to start off our day Well, welcome to cube by example insider where we talk to people who are directly involved in the creation and kind of continuation of Kubernetes and all the Insulari projects that go along with it as you can imagine Kubernetes is a large complex project and even things that aren't directly underneath Underneath the kind of umbrella of Kubernetes are still very much involved in the ecosystem And so we like to and because it's an open-source project. We like to talk to Participants in the community who are actually contributing work to the community because we feel like it gives us a better sense of where the The Kind of ecosystem is going Which you you know would normally get from like, you know, a roadmap event or something from a proprietary company We feel like they you know actually talk to the people who do the work makes a big difference So I am a clinical faculty member at Boston University formally at Red Hat And I will kind of go around and just introduce to you. Do you want to introduce yourself? Sure. Hi. Hello, everyone. My name is Savita Raghunathan. I am a senior software engineer at Red Hat working on data prediction I was here as a guest on the episode number five and I loved the show so much And I got this opportunity to be here as a co-host today and I am Excited to talk to Travis About Duke and more exciting stuff around storage. I'm a big fan So it's an honor to be here with both of you and in the community Moving on to Travis. Would you like to say a few words about yourself? Yes, hello, Travis Nielsen. Happy to be here to talk about Rook Rook is what I do for my life. So I'm always amazed how many people want to hear about it and Learn more but yeah, I'm one of the original founders of the Rook project and that's really where I Got into Kubernetes and that whole ecosystem. So it's been a great journey. It started about six years ago and before that I was at a Startup called sim for I'm doing a diff distributed storage and before that Microsoft. So I've been in the storage area for for most of my career Yep, that's me in a nutshell So so Rook brought you to open source what I'm sorry brought you to Kubernetes But what brought you to open source like were you involved in open source before? that work No, it's really the the same project we At the startup I was with was in form. We thought about well should we open source what we were working on It never really worked out while we were on that project But then as we got into the next things which basically turned into Rook That's where we really got into open source Followed a lot of patterns that we saw in the Kubernetes ecosystem About how to like do a successful kind of open source project to me Yeah, and I guess it maybe it's too long ago to remember now exactly how we got into it But it felt like yeah as we got into the open source world We yeah, we just looked at well how are other projects doing it tower You know, how do we do releases? How do we do? You know, even things like rebasing and PRs and Dealing with git a lot of we wanted to make sure we were following Patterns other people were using so I think Kubernetes was one of those projects We were looking at early on just to make sure Since it's such a big ecosystem. Well, right if you're not doing things out there doing it, then maybe we're not doing it, right? Right, right Good Look has been successful. So thanks for sharing that little bit about like how We look up in the community. We take the good portion of it and how to create a successful project and it is the first graduated Storage cloud native storage project in the CNCF community. So how do you feel about that? Like Can you share this a little bit more on the success stories and like, you know more background on it on that? Yeah, great that it has been a nice journey and to become a graduated project It's already been I think it's been three years since we were graduated in 2020. No, wait, it's only 20 to 20 a couple years since we've been graduated But yeah, how this journey worked is so maybe I'll just go back in the history a bit. So back in 2016 When the Rook project started That's when we started to look at really wanted to look at well What's cloud native storage? What does storage mean in the cloud native world cloud native was kind of the latest buzzword back in that time Where really you want you want your software to work in the cloud You want it to work well in the cloud be designed for the cloud and We wanted to see well storage is we know is important for the world and and its storage is a really hard problem We want to make it work well for people So originally we looked at Seth as the storage project that we would build on and quickly learned that our retrospect, it's definitely a Good thing and it's been a great thing to build on Seth as the storage Platform, but Seth wasn't billed for cloud native. It wasn't billed for Kubernetes And so we thought well we need to bring this storage platform that's been stable for years already Bring it into the cloud native and Kubernetes Ecosystem So initially we were thinking well, let's make make it work well for any cloud native environment whether or not it's Kubernetes or not what initially we didn't even start with Kubernetes. We thought oh, we're going to build kind of our own Installation system for this distributed System and we quickly realized well if we just build on at CD and Try and use all those primitives. It's just going to be too complicated Why would we do that if Kubernetes is already doing all of that for us? So that's when we really took a bet on Kubernetes and said hey, this is the Platform for distributed systems Let's let's build storage the storage platform on Kubernetes since it gives us that distributed platform for free essentially And then yeah from there like we created an operator and I think around 2006 yeah that first conference in 2016 also we went to the Seattle Kubecon and there were maybe a thousand people there So, you know, you know how big kubecon is now 10,000 people or whatever. It's grown a bit So it was still pretty small The concepts were new and at that conference is where I believe Brandon Phillips presented on operators and operator pattern with that CD and and the Prometheus operators are the first two examples And while we were there We heard that and we thought wait, that's exactly what we want to do. We want an operator that's going to automate storage and bring stuff to to kubernetes so then Yeah, we immediately and pivoted and said Yep, we're creating an operator. We're gonna create crds. Well, they weren't called crds back then. They were tpr That's how old the project is But so we created an operator and then soon after that the Kubernetes community came up with this whole project or pattern for graduating moving from sandbox to incubating to graduating and so we We thought okay, we want this for the community We're open source just like It's expected in this community to progress so we worked through that We worked through that whole progression and we're happy to that the community was receptive of the project We got some feedback along the way for how we could make the project even more useful for the community And so it was it's just been great to see the reception then for You know, there's the seph community that already existed then any any of them who were using kubernetes said Oh, yeah, well, it looks obviously the the solution for us so we naturally had the seph community joined us and then Actually somewhere in there. I joined the seph team at red hat To more naturally work together and make sure we were building the right thing And and then I think graduation a couple years ago was the final stamp of approval where it's like, yep The community really sees the value in this. There's there's good production deployments lots of Testimonies of people happy to use it and and that it's You know open a community we want to do the right things for everyone. We're not Trying to favor any one company because there's there are maintainers for multiple companies and all that goodness that comes with the open source world and I don't know. I kind of went in a lot of directions there, but I actually uh, you said something Particularly interesting there. I was kind of curious to hear your thoughts on um, you know, you said Um, you know one of the things that you were struggling or like you and your team were struggling with uh early on was What does it mean to be cloud native storage? Can you tell me what some of the hallmarks of that you think are of cloud native storage? Like what what is different about it? I mean, I have my own theories, but I'd be really curious to know What made you uh gravitate towards that or what you know, what how did you decide to solve that or what or how do I recognize it? Yeah, uh, let me try and think back that far so the I mean when we think of traditional storage, it's like an appliance you buy you plug it in and and you connect your external storage to it and that's usually how Or it's still a common pattern with kubernetes today where to get storage with kubernetes. You've got Your storage classes which let you basically attach The storage whether it's inside or outside kubernetes The cloud provider plugs in their storage If you have an appliance from net app or wherever you plug in that storage and But how do you get storage that to be managed by the same cluster the kubernetes cluster where Where you're already managing other applications, right? We don't want it to be external We want it to be just native to the platform and that was the I guess that was the basic assumption was like we don't want it to be external. We want it to be Part of the same cluster. You're already managing and And then with that comes all the patterns that kubernetes has well, you have to run in you're going to be running any containers you're going which traditionally Really seph hadn't been running in containers. Although it was moving in that direction already You've got You know the concepts of your Your running applications your pods being able to move between nodes because kubernetes just assumes nodes can go down and you can move to other nodes and and just kind of naturally deal with The dynamic environment where things go up and go down and you replace nodes Nothing is static Anymore really So all of that just kind of being able to handle that dynamic distributed environment And be part of the same cluster as the rest of the distributed app um platform In my mind, that's kind of what it means to bring storage to the cloud native world And and so do you think things like eventual consistency are Kind of in line with the cloud nativeness or do you think they're you know Uh a way kind of around some of those problems or is that um or just anathema? Altogether, um, you know, I'm just kind of curious of your thoughts on because it's it's definitely growing in popularity And to me it seems like something that if you're kind of a true storage person you might be really stressed out about About the eventual consistency nature of it or Yeah, and seph itself Kind of has some assumptions that well, it's not eventually consistent It's it's fully consistent. Like once you put data in to seph, you know that it's replicated and Kind of that seph is taking care of it the difference being well, if it's eventually consistent then You know, you put it in and you might not get it back if you ask for it too soon, right? because the back end is Is replicating the data and until it's replicated then you might not get it back but seph Yeah, we liked the full consistency of seph for a data platform And so there's there's a little tradeoff there, which is maybe it takes a You know a touch longer to commit your data. Well, I mean we're talking milliseconds, right? But But that full consistency has been Yeah, we just really like that That solution from seph having a full consistency That makes sense. I was just kind of curious, you know, if there's You know, it seems like we're maybe getting to the point where we can do full consistency most of the time You know, if not all of the time. So maybe it's it's not, you know, maybe it was a stop gap, right? You know, that's why I was kind of curious what you're you're kind of feeling on it was So did you have a question? So I don't have a question. I just wanted to like say something on top of what Travis said before like I used to be a cluster administrator. So What I would look for in a cluster storage is always baffling. It's still baffling to me And I'm trying to like learn a little bit. Um, I am improving on my knowledge I wouldn't say it like I know everything about storage or cloud native storage for the pattern The one amazing thing about rook, I would say is that it has those things like How Kubernetes is self-healing Um, the rook storage operators is like it's self-healing. So it gives me a piece of mind You know, like I don't have to know about everything I just need to know about some basics and I can still Do my job and keep on improving my knowledge on the side It's an amazing win to be honest. So when you talk about like how you made it work with Kubernetes and everything it's it's amazing. I'm a fan and it's uh, it's It's marvelous in my head. Like I just see software. It's like things It's a beautiful piece of software. So I just wanted to add that That's great to hear. You know, yeah, I'd like to talk to that point too really because what we really saw is potential in kubernetes that The patterns there the basic pattern is you you need to declare desired state like what how do you want the software to behave? That's what you're telling kubernetes with these manifests these animal files, whatever you tell You tell the platform what your settings are what your desired state is And the operator's job is to go make that happen to make sure that you're Know that your applications are running reliably that so in the case of rook that means the the rook operator is going to be Making sure that oh the pods are all running where they need to run that You know that your cluster topology is handled that That the data is safe and replicated But if something goes down that we we try and start You know up a replacement somewhere else because there's that flexibility there And that that operator Has an amazing power to go make sure that things stay healthy automatically And so that's definitely been a fundamental design principle Of kubernetes that has really worked well for rook Yeah, so um, although you you kind of civita. I think you raised a good point like is You know, I guess my question with something like rook is like Is that where I should start in a sense or do I start with something like seff if I want to try to figure out How would you storage let's say in a You know in a development environment right now the necessary for the production environment where i'm kind of trying to understand How I want my storage eventually to work. What's the best way to kind of get started with it is You know, do I you know kind of do I start at rook? Do I start at nfs? Do I start at seff? Do I start, you know, where do I kind of get plugged into? Understanding how doing the storage inside kubernetes Like where's the best point to kind of start for you in your opinion All right that question was civita or for me Oh for you. I meant travis. Sorry. Okay. Yeah. Yeah, okay. All right. Yeah, so Really with with seff there are two Very different environments to run it in one is kubernetes and with rook and one is You know doing it on your own bare metal where there's just no kubernetes platform available so so upstream and kind of for downstream solutions those two Those two scenarios really remain both important and critical because some people just aren't on kubernetes yet More and more people are moving there, but for people who are Who are already running kubernetes? If they want storage then I'd recommend you to get started with rook to deploy seff because rook just makes it Excuse me. Rook just naturally deploy seff. It makes seff Easier to deploy and manage and upgrade and all of that So it's certainly possible to deploy seff without rook But not really in a kubernetes environment So and like in rook we have documentation on our website on rook.io where you can go there There's a quick start guide. This is how you get started with kubernetes and deploying seff And we try and make it as clear as possible. I know it's still storage is still a difficult thing There's no easy way to do it really and it takes a bit of dedication to get it going But it's once people get it going then I feel like they really Say hey, this this does work nicely. It works well for us and solves our storage problems really Cool, I just threw a link to what I hope is the getting started of the quick start in the in the chat of kubernetes look. Ah, yes And uh, also in kubernetes example, you actually have a series, right? Uh So, uh, you know, either one of those might be a good Start as well So I hear through the grape find that the origin story of the name rook is a good story And so I'm curious to know what that story is because I don't think I know Let's do that I have heard about it, but I want to hear about it again from one of the co-founders of rook. So Great Yeah, you know as with any project You know anything naming is kind of a big questionable. What do what do we call this thing, right? We're creating something new Uh, do we just call it seff for kubernetes? Do we you know, what do we call it? And well initially it wasn't even seff for kubernetes. It was for cloud native. Anyway Our our initial codename for the project was castle and where castle came from is we wanted to build You want to build something build a place that's safe for Um, something that's important to you that you want to protect. So a castle you you're protecting your your people You're protecting the king, you know, you got soldiers surrounding it. It's a safe place That's you know built on built with rock and stone It's yeah, it's a safe place. So castle was the original name of the project but then As it started as it came time to kind of look at copyrights and what other projects out there called castle There were there were a couple other projects called castle. So we thought well We kind of like our logo that looks like a castle. We like this whole theme. What do we do? Well, so then we came up with rook as um, it's you know, of course the The piece in the game Of chess, which is a castle and I think in arabic. It's rook is the word for castle It's a nice short word rook dot. Oh was available And we thought oh great. Let's go with this and it's it's been good ever since Um, I've got it on my license plate on my car now Yeah, it's just a nice just a nice short word that everybody can relate to from the game of chess and Yeah, to be honest, I can't believe rook.io was available to be honest, right? I mean, you know that It is a pretty common pretty solid word, you know, uh, so I'm I'm impressed you were able to get the domain. Um But uh, yeah, I'm actually familiar. Oh, isn't there like a Let's say it's a php web framework called castle. I think Um, which was probably there's something like that. It's been a while But I used to yeah, I mean that was it I can't remember someone had a trademark on it too. So Nice nice, that's cool. Um, so I should I should give kudos to someone who designed the logo too. It's it's one of the best um project logos that I've seen um, which I wouldn't mind putting it on my computer or like even sporting it outside so kudos to Yeah, we had a great designer on the team at the time and Actually, he's moved on with one of the other rookbounders to Um to up the upbound project. So if you've heard of upbound look at their designs Yeah, I love their designs too. So shout out to Shout out to him for creating the the rook logo Yeah, it's always handy. Um, yeah and and uh the naming of things I completely agree I was involved in the naming of modularity which led to real app streams modularity was a terrible name And uh, you know, but it was one of those ones where you know, we kind of started throwing it around and it's stuck Rather than you know, putting real effort into naming. I strongly recommend if you're ever building a project put some effort into Either coming up with a good name or an arbitrary name But uh, you know, uh an arbitrary name is often even less risky. Uh, you know, because that also lets you pivot and do things like that um But yeah, totally. Um, Savita, did you have another question you wanted to move on to or? Um, sure. Yeah, um, I have like many questions But I'm just gonna go in a tangent and ask like, um Tell us a little bit more about how to Contribute to look or like some folks are interested in like getting started somewhere. I know landon ad shared some um intro or links to intro videos and like where to get started but say Um, I'm a new newbie. I want to like learn I come I try it out. Hey, there is this thing that I want to improve on and I want to like start Contributing back so like can you share what's the path like for folks who want to like Start contributing to the project Yeah, great, uh, and I mean first of all we we love Love contributors. We try to foster an environment where everybody's Welcome to ask questions and contribute Um contribute back to the community whether it's with prs or with just answering other people's questions that come to We want an environment where Yeah, people feel feel welcome and that their questions will be answered. So You know on rook.io like we've already linked. There's the documentation for getting started There's also a link there to join the rook slack So in the rook slack, that's where we you know, really it's Uh intended to be a place where you can ask questions get answers And community members can answer each other's questions You know, I am frequently on on that slack as well answering a lot of the questions But it's just nice to see You know continually. Wow. Look at all these different people asking questions All the people getting involved in trying out rook and then Yeah, so the rook slack is important. There's In the getting started guide and in our documentation we have a Doc that's about How to contribute to rook. So if you really want to You know to contribute some code back Let's see How do I paste a link in there? Let's see where to paste it But there's in the documentation if you click on the contributing tab I can yeah, we have a whole Yeah, we have a whole topic there on Um, you know, here's how you set up your your github How you open a pr And all these little things for yeah, how do how do you get started as a as a contributor there For people who really want to get into the contributing and the coding Yeah, I'll just point out testing is an important thing for us so that we make sure we keep a reliable platform we've got CI that runs all of our tests and we really like to make sure things stay stable for every release and So what so if someone Comes and Contributes, we yeah, we just make sure every contribution is Is solid and and works for the community, but definitely welcome to those to those contributions Now there's github github is our main place for You know opening issues if you find an issue you want to report an issue Or there's also a discussions tab in github And then you know, of course opening a pr if you have a code or documentation suggestion there Um, so we actually had a question from the audience too. I think I found the link So I'm gonna post that real quick um And then uh, but we did have a question from the audience was um What is rook's relationship to databases? You know, does it does rook help me? You know deploy both grass or whatever in Kubernetes Yeah, so So maybe i'll talk about sef for a minute first as the data platform and how it Then works with your applications like databases on top of the storage So sef provides really three types of data storage provides block storage uh shared file system and object store So let me talk about each of those so block storage is usually where You have an application that needs Needs to create a volume provision of volume And that only that one pod is going to use that volume. So it's a in Kubernetes. It's a read write once volume generally Then shared file system storage with sef fs That's where well, you might have a pod that wants to share its storage with other pods So you've got to read write many volume And so sef allows that so sharing storage between pods is completely possible with that And then the the third form object storage is all about Kind of what you think of as amazon s3 which Initially created object storage where you're putting and getting objects Into into the storage platform. So So sef provides all three of those And you can choose which ones you want to enable All three of them or just one of them depending on your storage needs Um But for so databases now like postgres kassandra or any of those Typically databases would be created on top of the the block storage. So you create your read write once pvc provision the volume and then You will would write to that your database would then write to that volume that sef volume Just like it would write to any other volume That you might provision So yeah, I hope that Gives us overview there Yeah, so basically what you're saying you kind of like you set up the storage with rook and sef as block storage, right? And then you would kind of install your database normally And it's just that it would be Kind of getting it storage through this kind of automatically replicating or distributed files well block store You know to be specific. Is that a fair recap? Yeah, that's right. And another example. I guess if you're running an aws You know your database might be backed by an ebs volume Uh, or I mean if you're not running any of a aws, you're running somewhere else where you If you're in your own data center where you configured rook, then it would just you'd just be putting it on top of a sef Block storage volume instead of the ebs volume Right, okay So venten who is the person who asked the question? You know feel free to add follow-ups if you have any more questions What I would like to kind of move on to is You know kind of as we talk about with the insider show, right? We talk about kind of what's coming, right? So what what are you most excited about from a kind of a feature perspective or Improvement, you know, maybe it's stability. Maybe it's something else, you know That's coming in say, I don't know the next six months or or so About rook and in or even about sef, right? Like, you know storage available to kubernetes Yeah, and now we have several engineers working on rook full-time So there's always improvements. There's always something coming And and maybe I'll talk to our release cycle just briefly So every about three or four months We kind of tried to follow the kubernetes release cycle, which is about I think three times a year now every four months is the goal So we're about on the same schedule that we'll have a release Our next one will be coming up in august. It's planned for rook version 1.10 So in And really where where rook is feature-wise, I feel like I'm just happy we're We're I feel like it's stable. We've got the basic feature set. Now. We're we're still improving. We're still adding features, but the basic things are all there Like one feature we're looking at for 1.10 is the ability to say It's kind of at at the sef level to be able to say, you know Keep track of who ran what command like what's the operator doing versus what is a user or admin Doing to manage sef in what we call the toolbox the toolbox is this This pod that we make it so you can run sef commands to if you know what you're doing with sef you can go run those commands there so at kind of making it better at the Logging level to so we know what's happening. We can keep track of that I mean, there's already logs. It's just we can't tell who's doing it if we're looking back at logs So that's maybe that's one internal feature that I'm excited about but most people probably wouldn't even know this Look there's that other features we We did recently add an nfs driver to rook and it's a csi driver so That people who have legacy applications that use nfs and they want to kind of come into the kubernetes world and convert to kubernetes then We've got this nfs driver that makes it so you can Connect your storage with nfs that's that's the external storage and then kind of convert it into Rook storage so you can get away from That nfs storage and convert it into sef So that's another big feature area that someone else on my team has been working on happy to have that one and There's always someone it's so much going on with the project I'm going to forget them on the spot, but That's a couple of ideas For some pretty cool um I think the nfs Right, it's going to be a music to sell many people because they like large companies And many of them have their on premises. They are centers still even though they use cloud and for predominantly for the on-prem They would be reliant on nfs Most of them use nfs. So yeah, it would be like amazing for them to even adopt communities at a faster rate, you know, like what than what they plan so That's cozy here in the world and Until you mentioned I only thought that oh, it's gonna work with uh sef and whatever sef reports the block the object and I forgot I don't want to fast when I have it. I just cannot say it Okay, thank you. So, uh, I didn't know about that of us. So Thank you for mentioning that Yeah, then we always look forward to community feedback as well to say what features do people want to see Yeah, there's always a You know those feature requests coming in that we're happy to entertain sometimes we We say yes, that's a gradient sometimes we say well Do you have the bandwidth to work on that because sometimes we just don't have the bandwidth As with any software project, I think Yeah, kind of getting to that. So you said your release schedules, um, you know, for sorry three times a year Is you know, particularly the storage, right? That's something that tends to be You know, both jokingly and seriously. It should be pretty stable. Um It how how does you know, how does the user base feel about that kind of release scheduled? Is it, you know, or how do you manage to the fact that You know, the thing that I don't want changing in my environment is the storage, right? Because I wanted to always be there and I wanted to never, uh, you know, never go away What's the you know, how does how does rook and and sef deal with that? Um, those updates That's a great question. And so so one thing I want to Maybe talk about now is so the difference between Rook and sef like because they each have their own responsibilities So rook's responsibility is really to provide the management Of of sef So we I talked about the rook schedule as okay, how often are we releasing so that you can get improvements to the management layer right but Deciding you can separately decide which version of sef you want to be running In rook. So you tell rook. Okay. I want sef You know version 16.2.10. That's the latest version of of stable sef Or 17.2.2 depending on which major version you're on So you can decide Which different version of sef you want to run and you can decide to update sef Much less often because sef is the data layer. You really want to be careful with What you're doing With that data layer. You don't want it to go down. Yeah, you want it to be super stable and you want to be Really mindful of when you're updating that data layer and and this is kind of thinking about architecture in retrospect Like three years ago. One of the major changes we made was Decoupling that sef version from rook Because originally in the project We basically embedded the latest version of sef with rook and you couldn't choose what version of of sef you deployed and so we kind of would you know, there's We would force that That data up data layer upgrade Whenever we up to period rook and we realized yeah, that's People really do need that mind That piece of mind that they're getting a stable data layer. And so we separated it We said, okay, you can choose your version of sef that we deploy with the sef demons in those pods And rook will have its own version in with the rook operator basically so that Since those are fully separate now sef has its major releases once a year And you know, rooks is three times a year so if you don't want to Upgrade the sef layer as often Then you can choose to do that You probably should do it delayed, you know upgrading to the latest patch release of sef is a good idea anytime it comes out generally But then you can choose when you're ready to make that jump to the major upgrade of sef Which rook usually makes pretty smooth because Our goal is to make sef deployment and upgrades simple and automated But yeah, you just need to be aware of when you're upgrading so You can be ready in case something happens We had a couple more good questions from the audience. One that I think is relatively straightforward Which is does rook work with okd and open shift? And I would say yes And just look to travis for confirmation, but I can't imagine why it wouldn't Yes, absolutely, but rook runs anywhere kubernetes runs and you know people The are the most common scenario I would say is that rook would be running in a bare metal cluster where you don't have other storage options available But at the same time there are a number of scenarios where People use rook in cloud providers where there other storage options are there with the cloud provider storage like aws or google cloud or whatever and So yeah run everywhere and in cloud scenarios the main difference that that really benefits rook users too is that You can tell rook to back the sef storage by the cloud native storage So if you're an aws you can say oh back sef by ebs volumes and now The limitations of ebs can be overcome by sef because now You know, it's for example ebs volumes are limited to an az and you can only have so many volumes mounted on per node Like 30 last I heard that might be out of date though Some limitations like that, but now with sef on top of that You can have storage across azs. There's virtually no limit to how many volumes you can have You get the benefits of large ebs volumes, but you can have small volumes with sef since it's often the proposed provisioned And anyway, so there are lots of benefits to that as well So yeah, I think I think from your original question me So no, no, no, I I thought it was good. I was just kind of like I wanted to also kind of make the point that you know Open shift okd are really like an open source vanderized version of kubernetes, right? I mean, so the end of the day it's still kubernetes underneath So as a result anything that works with kubernetes should work with open shift okd including rook so But then we had we just got a whole influx of people, you know, welcome to The brazilian people from linux tips brazil But what I wanted to also ask is there was a question also from the audience, which was Does work work with other storage providers like net app? And again, I think this is just hopefully a straightforward answer Yeah, I mean if you have have a net app You're probably going to use like a with kubernetes a storage class that consumes that net app storage And so rook probably wouldn't be involved there if You could also choose to back rook by some other storage as long as there's a storage class rook can Consume that storage behind it. I'm not sure. I've heard of someone using net app In conjunction with rook and stuff Usually that I would say they they're in parallel or you can have Net app as well as rook Um So it's a little bit of both both and right or you know and or depending on on your perspective You know what you're trying to accomplish, you know, and I think we were talking about this a little bit with on the in the chat of like You know databases often offer replication, right? but then storage particularly these days right distributed storage also offers replication and Depending on your use case depending on what you already have set up or whatever like You you want to choose one or the other What you don't usually want to choose is um trying to have them like fight, right? You know, you don't really want database doing replication and your store is doing replication because often that will go poorly Uh, you know because one gets confused about who's responsible for what I think the the same kind of thing happens potentially with something like net app or or whoever your storage provider is Where you you know, it's like make sure it's very clear to all the software involved Who's responsible for which bits, right? and it's and you get into trouble when you try to Kind of just take all the defaults from everybody Without really thinking about how much they potentially overlap It would you would you largely agree? I think that's the problems. I've run into the most Yeah, exactly. You can have multiple solutions. They They can overlap. I mean not in responsibility, but yeah, they're very independent I was gonna say something else, but lost that thought anyway, maybe you can come back to it. We had another question, which was kind of You know, I think interesting, which is basically like Does rook with sef support the concept of like a data lake? versus, you know, traditional storage in a sense Right, and I know I've heard the term data lake, but I'm trying to think how it fits in with With sef when someone yeah, when you think of a data lake What can you expand on that scenario a bit? so for me, uh, like a data lake is kind of like, um An even less well-defined data warehouse. Um, so in other words, um in in my opinion, right? This is where um Again, you would be using some sort of software that is doing, uh, the data lake like, uh, the one I've been investigating lately that I haven't read That much about it's called delta lake. I think um So kind of again, it has a responsibility of managing that lake And so what you don't want to do is have rook and sef try to manage the lake On the flip side the lake itself could be managed by a delta on top of something like sef And then you kind of could expose it through your kind of kubernetes environment, but this is where it gets a little Dicey about like this is one You know, it's very specific to the scenario that you actually want to deploy Um, and so kind of giving a general answer is tough. Um, you know sef's storage So you can run your lake on the storage or you can try to build a lake Uh, you know using like rook and sef the problem is you're not going to get what You get out of something like delta lake. Um, you know, the feature set there. So Right, right. And what I'd say is, you know, rook is Really targeted at managing a storage for a single kubernetes cluster. So if the lake were to try and span kubernetes clusters, um, that's not so much Uh, a thing for sef. Although I will point out that sef and and rook helps provide the features where you can mirror data across clusters So if you have your block It's sef rbd volumes you can mirror them to the other Cluster and so whichever type of volume you can mirror it to the other cluster and get dr So there's documentation how you set up dr and get failover and things As well across clusters Is is multi cluster support for rook? on the kind of roadmap or is that or or do you think that the Kind of current solution doing it with sef is is the right answer in a sense or or at least From what you know today, right the right answer Yeah, and as of today, I'd say Rook, you know, rook upstream is really just targeted a single cluster if you have multiple clusters you're just going to be having multiple rooks and You could configure each rook to mirror if you want To mirror the data across But ultimately Yeah, we don't Really have something in mind for multi cluster support. I think for You know for downstream there's I know red hat has like this acm project that's for managing multiple clusters So I'd say it's more of a downstream thing in my mind Or at least not a rook Problem we're trying to address Yeah, this is actually one of the challenges. I think with kind of the multi cluster management in general with kubernetes is like From a operator perspective, you know single plane of glass Into all of the things you're kind of managing is nice But i'm not sure that all the things that you're managing need to be aware of each other So in other words, you know, you might have 67 rooks as long as you know from an operator perspective Sorry, when I say operator, I mean human operator From an operator perspective, I want to know about the 67 But I they don't necessarily I don't necessarily need them to literally be Just one that is being managed on its own Instead, you know, give me a kind of user interface that lets me say This is how I want rook to operate in all 67 or I want rook to operate in this way for 60 of them and set You know another way for seven, but that's kind of They're not operating as a cluster. They're being individually managed at a kind of a step back level I know this is One of the before I left red hat actually acm was was starting to come up Um And it's it's one of those difficult problems of like who owns which part Yeah, and I what I'd say about if you have lots of clusters probably you're going to be Automating things scripting things So you get consistent configurations across clusters because rook is all Based on you know that the yaml manifests We've got helm charts as well for people who like to use helm So so those would allow automation across clusters for sure And then to monitor what's happening in the clusters You know, there's a lot of functionality around you know the prometheus Monitoring so you can collect metrics you can see dashboards about how sep is Is behaving in the cluster and things like that so you can get insight for sure With those other tools Like prometheus and grafana Which yeah, which a lot of people really appreciate sep also has a dashboard that you can connect to the individual cluster and see more details for what So I wanted to pause there because we are almost out of time We do have a number of other questions in the chat So i'm going to put the kubernetes by example forums in the chat So please go open a topic there or you know anything that you're interested in and we'll try to You know make sure to come back and take a look You know and and respond to any more questions that you might have We want to I also would like to pitch an upcoming conference that is all about open source development And it is called devconf.us There is an analog In cz, which is actually quite a bit there sorry in the check republic But that is in january and this is actually next month about the middle of august And so I I want to say we actually have at least one rook talk there, but I could be crazy I'm trying to remember even though i'm a co-chair. There's enough talks that I can't remember them all So definitely check that out. It's in boston We're going to be doing some streaming of it, but it is meant to be an in-person conference So hopefully you can make it it's free as with a lot of open source things So check that out Let's see. I think that was all But we would of course really like to thank travis for coming and talking to us about rook Travis, is there anything that we didn't mention that you wanted to kind of slip in there before we go? Yeah, maybe I'll throw out there that With kubekans. Hopefully with we're doing them in person going forward again I'm looking forward to that. We always have a rook booth there. So If anybody's a kubekani, be happy to meet you and talk to you at the the rook booth It's the easiest place to find and there's always the work talks at that conference as well So looking forward to the meeting people To detroit in october And uh, yes, that should be that should be fun. I will also be there actually We're going to be running a a kubernetes by example insider day maybe or You know, I we're going to definitely kind of walk the floors and try to interview people So we'll we'll definitely be there and involved as well But yeah, thanks so much again for your time and we really appreciate it. Sveta. Did you want to add anything else? Uh, no, this has been amazing session travis. I was like Um, I learned a lot and I hope all the viewers the community learned a lot hearing listening to today's episode and thank you again uh for being here taking your time and chatting with us about cook and storage and stuff and um Yeah, definitely simplified Some topics at least for me Uh, and I hope uh, it's going to benefit everyone outside. So thank you for that and I don't have anything else to add. I'm like, I'm a big fan. So I'm like In all I was just listening to both of you talk. Uh, it's been wonderful. Thank you All right. Well with that note, uh, thanks again travis. Thanks to the audience. Uh, thanks to the I think it was brazil then accepts And uh, you know, maybe we'll see you at the big brazilian open source conference, which i'm blanking on the name of I know a bunch of my friends regularly speak there. Uh, and uh, you know, hopefully we'll we'll see you soon Thanks again for coming. Remember, we're on the last tuesday of the month. Uh, and uh, we hope to see you next time Thanks everybody