 All right, then, welcome to our first group talk of the day. Please welcome with me Alex on Rook intro and what's new in Rook. Thank you. Well, first of all, technology works as we want. So, I'm Alex Hennar, I'm a DevOps Engineer at Cloudical, I'm one of the Rook maintainers and, well, certified Kubernetes administrator. So, before I'm just jumping into the topics, quick point that you see on the rough outline on what I'm going to talk about. First part, Kubernetes and storage. Just a quick point on how is it looking in Kubernetes, what's the situation? What is Rook? Did you, well, get kind of a bit of an overview on what is Rook even? Architecture, and then we're going to dive into the new features, also in the roadmap for the future, and just as a last point to throw in, we are looking to graduate the project soon. So, I'm going to talk about that in a bit as well. So, Kubernetes and storage. In Kubernetes, if you want storage, you're well basically bound to use external storage, meaning, well, taking on-premise with bare metal as an example, you need to have some sort of storage already existing. Not to name any names, but, well, there's bigger appliances for storage you might have. Well, if you're just on-premise, that might be already enough for you. But in general, with the storage there, it's not too portable, meaning that if you go from on-premise and you're on the multi-cloud, hybrid cloud kind of trip, well, your appliance in the data center might not be sufficient for, well, your AWS or whatever cloud scenario. So, well, as we have it, if your appliance is in the basement and not in the AWS cloud or GCP wherever, well, you need to have access to the services. That's not so much of a challenge if you're just on-premise, but, well, it's in general just like it's not too portable unless you are in the same environment all the time. For if you're more or less in a cloud environment, the problem that arises is, well, you're kind of locked in because if you're with AWS, well, you can use their EBS and their, well, their file system and, well, S3 and so on. At least S3 is a bit more open, if you will, so, so that's not too much of a problem, but normal, well, classic storage like block and file system storage is kind of a burden to have. Well, switching from environments. Even though as we have in Kubernetes storage classes and such, which kind of are, well, a bit of an abstraction there, well, it's still a bit of a challenge because if you have a bug on, well, on, let's say, your local appliance storage and you move it to AWS and you don't have the bug there, well, there's certain scenarios where it's simply a bit more important to have the same storage from your on-premise or whatever to full production, so, now. And another point, well, if you're a big company, you probably don't have to too much as a problem, you need to have someone that manages the storage. So if you just put some appliance in and, well, it runs, then, well, you might not need to manage it too much, but still, at least it feels a bit weird to just put in some appliance and, yeah, it runs, it runs, and it runs till it doesn't run. Yeah, well, so kind of the question there, who's managing the storage? So that's where we come to what is Rook? Rook is, well, a storage operator. The part of the operator part, I'm going to go into that concept a bit further later on, the part of operator is simply as it kind of implies. Well, I'm, for example, an operator to, well, operate, well, some crane or something. It's kind of the same, if you think, for Rook there, it's, well, operating things like SAV, edge affairs and other storage systems, storage software, back ends, providers, how you want to name it. And the point with Rook there is that it, well, do you have Kubernetes? Well, fine. Put Rook on it, you have SAV, for example, or edge affairs, or it's generally not just about SAV, there is general point of those, well, complex storage systems making them easy to run in your Kubernetes cluster. So, well, in containers in the end. And the part of, well, where the Rook part with the operations is coming in is, it's trying to have it as abstract as possible, but with also a good amount of customizability for the users, where Rook takes care of deploying, managing, installation, configuration, this 100 steps, and, well, in the end, you create one or two more objects to talk about the Kubernetes part there, and, bam, SAV cluster in your Kubernetes cluster ready to be used by the applications. Well, if you want to bring that to production, there's a bit more to think about, like, what's kind of distance on, but, well, kind of, if you think about more on a lower level. Still, remains that Rook will take care as good as possible about those points for storage software. But, well, let's kind of step a bit back there. Rook, it's open source, a package point serial license. We are a project of the CNCF. We currently, that's also, later on, we are looking to graduate the project as other projects like Kubernetes, as well, have already done graduating from CNCF, so we're trying to do that as well. As we had with the operator part to make it easily possible in Kubernetes, we can introduce so-called custom resource definitions. There's basically, well, a possibility for users, especially more, well, administrators of the cluster, to extend to Kubernetes API. So, well, for Rook, looking at CEF there, we would, for example, have a CEF cluster object for, well, other purposes, like, well, MySQL, for example, you might want to have like a MySQL database or something object, which, especially looking at, well, user experience for the developers, if they need a database, well, go ahead and create your MySQL database object and some operator in the end will take care of creating all the things needed for the database. It's the same concept there for Rook. The admin, hopefully not just all the users on the cluster, creates a CEF cluster object, and based on the specifications in that object, Rook will take care of, well, for example, for CEF to create OSDs from the disks in the servers, will discover them and, well, create the command structures and all needed to, for example, then tell CEF volume to use those in those disks based on these specifications. Yeah. I already mentioned that it's not just about CEF. It's also about other storage, which, well, is, yeah, well, complicated to run. CEF. Cockroach should be Atrofest, Cassandra, NFS, YugobarDB. Kind of shout out to the YugobarDB people. They just joined with, like, version 1.1. Great people. And, yeah, the idea is to grow that even further. So it's not just as, like, CEF or something. The idea is that, in a broader sense, well, I have my own premise, for example, I create my CEF cluster using a root CEF operator. And, well, I need a, well, YugobarDB. And I create it and just, for example, tell it to use as normal Kubernetes flow to claim, persistent volume claims is a key word there, the storage, for example, from the CEF cluster. Because why not? So, yeah. Going to the architecture. There's, in itself, three layers. You have the operator layer. It's, well, managing the CEF. It's configuring it. But the main point to mention is not on the data path. So there's no, well, my one operator part right now is down. So, oh no, everything's holding. I always stop. And that's not going to happen. For storage provisioning, thankfully, through the CSI, the container storage interface, it's, well, it's amazing as it's not just, well, for, there was something previously. Don't remember, like, don't, well, it's not too important. It's flex volume. Point is with CSI, it's more like a common solution for general storage. It has container storage interface as a name, but it's general interface to more or less be able to say, hey, give me 50 gigs of storage. And then on a note to say, hey, please mount the storage, for example. And that's great. Previously we had written our own flex volume driver. And, well, it's a pain to maintain such a driver. So, but it's also for, it's not just for the SAP part. It's also for HFS, for example, as they're also providing block storage and file system storage. Rook takes care of setting up the CSI driver as good as it can, like there's definitely some points where, well, the admin needs to step in to create storage classes to maybe, well, have certain changes, certain security levels specified in a storage class or something. But main point is that Rook will normally get you for some of SAP HFS class in a state where you just need to create a storage class. So, yeah. So, as previously said, for the operator, the operator is not on the data path. So, no need to worry about operator crashing or anything or being incompatible. It's just SAP or HFS or Cassandra and so on. There's, well, yeah. Yeah. I mentioned previously, like Rook SAP operator and there's even Rook HFS operator and so on. The point there is that it's separate operator. It is not like, yeah, I want to use SAP. But because I install Rook, I have the Rook SAP operator, the HFS and so on operator. That's not like it. That's the reason why it's split like that. If you want SAP, well, go for the SAP operator. If you want, let's say, Cassandra is an example used to Cassandra operator. So you have the freedom there to kind of say what you need and what you want. So, yeah, well, as said, we have the Rook operators that do the management, configuration, upgrades and stuff of the software. From, as previously said, with like the operators, it's basically the same. The operator is simply, well, automating certain actions which normally you would need to do. Or, well, maybe even another automation tool, like, well, Ansible or something. So, yeah. Coming back to the custom object. If you create a SAP cluster and say, hey, I want to use, for example, well, my STB drive or something, or maybe my, well, you add a new disk in that definition and say, well, use my STC disk as well. The Rook operator will take care based on that. And, well, we'll see, OK, to stay changed and act on that. We'll trigger all the things needed, all the preparation jobs, for example, for the OSDs. And you will hopefully in a few, well, let it be a minute. Sometimes LVM and so on takes a bit of time, at least for SAP, as a volume part there. But, yeah. So in the end, operator watching over everything, seeing OSD changed. I need to do something. And even kind of like health checking to a certain point where it's like, oh, we can't upgrade now because the status of the SAP cluster right now says we have data, well, OSDs down or something like that, too many or so. There's parts where the operator kind of tries to also throw in a good amount of knowledge from a people that run SAP cluster or even, well, more or less also the developer of SAP. Well, for example, there's like a, what is it called? SAP, SAP to stop, I think, and SAP to remove command and such. And there's parts where Rook also tries to, where we're more and more also moving there to use the SAP native parts to, well, have the cluster operator save as possibly. So, from the Rook part, operator part again, which is simply is the Kubernetes API. There's not too much magic involved. It's just normal power of Kubernetes. Nothing, well, too special there to say. As I said, it's managing upgrades and such. It's trying to do them as already for, like, SAP and so on is, well, stateful if you want. So, coming back to your customer service definitions. So, we have those customer service definitions and in those, the admin specifies what they want. They can specify one device after another. They can even, if they're, well, in AWS environment or well, in the cloud environment in general, they can even specify that storage should be taken from, like, the cloud provider and such through, again, like, standard Kubernetes methods, persistent volume claims and such and, well, just a normal way of kind of doing it. And the object is basically in the end, as Kubernetes wants it, it's the state as it's desired. So, there's not, the Rook operator will try as long as possible to use the disk even if it doesn't exist or, well, there's magnetism simply to hopefully prevent that but just from a, just from a Kubernetes standpoint, if the object says, hey, use this disk, it would technically, well, try it forever because the user wants to decide state to use this disk, so, now. So, moving on to the new features. You got a, you got a DBA joint in 1.1. We're already at Rook release 1.2, but, well, yay, new storage back end. Same goes here. We are a perfect example right now for the CRD party, customer sources. We can define our own objects or even, well, own APIs and the people that create those CRDs can basically put in whatever they want and even have, which is pretty powerful about Kubernetes, have validation and such in place. EdgeFS, EdgeFS has been able, thanks to G1, I think I'm butchering the name. Mustafa has implemented multi-homed network. That's a big challenge a bit still in Kubernetes. I can tell you, at least just from general concept there for the, well, for the, for projects such as MULTUS, if anyone has maybe heard about MULTUS yet. The idea is simple to have, again, Kubernetes native customer resources and such to be, to easily be able to have multiple interfaces from the node, but even virtual, well, overlay networks and such per application, per pod running in your Kubernetes cluster. Well, he didn't just design it. He even implemented it. That's great. That's cool to see. Just kind of quick look here for, again, part. We just specify a new part of configuration. In this case, I think there's even not just support for MULTUS, but I can't get the name right now. But one of the other projects that's allowing custom networking stuff in Kubernetes and easily configure those networks to be used for these, for this EdgeFS cluster in this case. For Seth, I think a lot of, a lot of people, including me, well, having kind of desperate for this feature. Partitions. Finally, at least to kind of bring up what my case is. Maybe who knows Hatsnop hosting provider? Anyone, maybe? Well, they have cheap servers and you, but you have two disks most of the time, and those disks are most of them, like four terabytes, eight terabytes or something back. And if I have my OS on one of them, I basically lose the whole disk because previously I couldn't use a partition, which, well, I would, one hundred gigs maybe for the OS and the rest for Seth, because why not? And finally, I think the, yeah, since, well, with the upcoming, I'm not sure if it's already out, the 14.28 release though, that is available as a feature to use. Yeah, it's great to see, it's awesome. So, big thanks for everyone that's contributing, helping, being on the slack, just, well, also thanks for being here. Yeah, so for the roadmap, well, we just try to further stabilize the customer service definitions, try not to, well, change them too much as we are on a stable level for a second edge, as for example, right now. We, well, we try to use, we have, well, we have our own code that does like the watching on the custom objects and such. Well, it's, well, there's a bunch of other projects out there as well, which kind of offer a more, well, more commonly used approach to doing that, like the operator SDK from right at chorus, I think there's two projects slash companies. So, the idea is to, well, move away from our own stuff and get something which, well, everybody uses. Yeah. As we had it with UGA-byDB joining for 1.1, we hope to get more storage providers on board with RUG for SAF. I talked about the multi-hom network stuff for HFS. Well, it's soon also coming to SAF in, I think, let me, in where you heard it. It's planned for around 1.3 thanks to Sebastian Hahn again. Yeah. Let me go back around and slide here. And for SAF parts, the manager part, who knows about the SAF manager? Who knows about the SAF manager dashboard? Well, the idea there is, there's a cool dashboard where everybody is working on to, in general, have better integration with such orchestration tools, like, well, the deep-sea stuff and so on, like the existing, well, RUG also exists, but also for RUG side to even also better integrate it with that. That's one of the ideas, Daniel, is that you can specify everything you want in the SAF cluster object. But if you want, you can also just log into the dashboard, see which disks are available in each node and then just click, click and say, oh, well, make the most of these or something. And, well, we want to get there. We're not quite there, but it's getting better and better. For HFS, they simply want to feature, well, to support new features that they have implemented in the project themselves. And one of the bigger parts here definitely is the CNCF project graduation, but precisely, there's more to come. So we saw that, project graduation. I'm not gonna bore you too much with dates or anything, the point being we joined the CNCF project as a sandbox project in like 2018 or something and, well, we further improved and so forth and, woo, point being, we tried to graduate in 2020. So hopefully around, well, March. And, well, besides looking from the past to now, well, a lot of numbers have increased so that should probably mean something good, right? It's growing to summarize that slide. Rook is growing further and further. We have done also, which is for a good amount of companies, also very important, there was a security audit about Rook, well, an independent security audit. Was performed by the Trail of Bits guys. They even did the Kubernetes security audit by being, there were some vulnerabilities. We fixed them or we're just one or two small, like, well, not two critical things which are still being fixed. Point is we got the security audit. It looks good. We didn't have too many critical things in general, just like the coin fracture stuff. We need to improve a bit on the CI part and such and, well. So should you run Rook already? Who's running Rook in development or so testing around playing with it? Okay. Who is running it in production? Oh, well. At least a few ends. I'm happy about that. If you want, like, I would really encourage you to get in touch with me maybe now or you can also just send Jared once a message on Slack or on Twitter and, well, kind of talk to him that we get a bit more, what he's called, not customer testimonials but testimonials about people using the project and, well, using, well, using it simply. Yeah. And, well, for people that might not be able to say, hey, yeah, we're using it, it can also be confidential. So, well. Well, I'm working for a classical justice point. If you want to work on Rook, like to program Go or something, feel free to reach out to us or to me. But now, getting back to Rook. If you want to get involved, feel free to jump on our Slack. Rook.io is also a great place in regards to the documentation and such. Twitter, we even have a mailing list. We have community meetings, so feel free to join. And, yeah. You got the photo? Thank you. If you have any questions, feel free to ask them now. I'll try to repeat them as we will. Some audio issues. Yeah. So, the question is that there is an issue about extending persistent volumes slash persistent volume claims with Seth Caesar, right? Yes. Yes. That is solved. Well, it's solved. It must have to be that guy. But it's back-pointed as far as I know to 1.2. Something 1.22. Yeah, it is in 1.2 as far as I know, but not released yet, or it is already in the latest patch release. Point being, Seth CSI, which brought this feature, which is the, for them, the 2.00 release, has brought this feature finally. Probably worth checking out github.com slash Seth minus CSI. I hope they've updated their feature table below. Yeah. So, the question is, is it possible to use multiple, well, Rook storage operators, for example, Rook Seth and Rook HFS in the same cluster? Well, technically speaking, yeah, sure, that's not a problem. They're self-independent. Well, if you use the same disk for both, there is a chance that, you know, one might take a disk first before the other or something, but, well, it's, you have two people fighting over the same disk, for example. Then it's not a clash of the operators because they don't know about each other, but just a clash of the disk on the servers. Yeah, if you separate, like, what nodes they use, then it shouldn't be too much of a problem. Yeah, it's like the same with, if you use Seth and the Cassandra one, you don't need to use the Seth one. In the end, it's just normal piston volume clamp storage, and if you separate, and so it's, yeah. Yeah? How is it evolving? So the question is, let me try to summarize it. How far Rook operators will go in regards to second-day operations, right? Well, one of the main parts, at least it's already covered by the operators, for example, for Seth, that's, well, the most common I know there, is the health checking of the monitors. Because, well, you don't want to lose your quorum. Well, bad things will happen then. In regards to backups of volumes and such, that's not a thing Rook is looking too much into. Simply due to the fact there's already a big ecosystem around it, like, let me, where do we have it? From Stash Project, the Stash operator, well, it's even an operator which has CRDs as well. There is Haptio, or well, it was previously, I think it's VMware or something now, with their Arc project. I hope they didn't rename it as well. Yeah, Valero, yeah, the new name. And there's a few more projects, some even more on the Seth layer, for Seth for example, like Becky too, I think. It's second-hand operations, but it's something just due to the diversity there. Do you want it in communities? Fancy with customers, those definitions are more outside. Just back up everything, for example, well, and at least one phrase that's kind of stuck with me from some people that do a bit more in regards to Seth is, if you want to back up Seth Cluster, put in our Seth Cluster besides it, and it's like, well, yeah. Yeah? Howdy integration? So you mean if you want to add a new storage backend, basically? So the question is what you need to do, basically, to add a new storage provider? Well, we're trying to improve that even further now. The main idea is that we have a lot of, well, framework-like structures to call it like that. Not yet at a, I would say, full-blown framework for that, but there's basically certain structures already available where you design your customer service definition, and, well, to put it like that, you can copy and paste certain parts of the codes, which, for example, just do the easy part of watching and notifying your own functions then to, well, on ads, like a new object has been created, you react to it and such. There's a good amount of functions already available. It can be still improved, like I said. It's more like we're moving more and more to be a framework in that regard, yeah. Okay, any other? So the question is, if one Rook-Saf installation can support multiple clusters, to a certain extent, yes, you would have, let's assume the following. You have one cluster with the Rook-Saf on it, and you have, let's say, three other clusters, three other Kubernetes clusters. You would use Rook-Saf just as normal in the first cluster to get Saf running, and in the other three clusters, you could also use Rook there to, with the, I forgot the name, external cluster integration, where you would take the access key and such from this cluster, give it to each cluster, and then the Rook-Saf operator can also set up to certain things like CFCs and such. Though one important thing there to mention is, the Rook-Saf cluster, you need to run it with host network true as of right now, because the other nodes and such need to be able to access the OSDs and the months and like, well, everything in the end, so that's one of the kind of restrictions as we have right now, yeah. If you don't have any questions anymore, well, I got a few stickers still with me, so feel free to grab them. So, yeah. See you.