 Good morning. Good afternoon. Good evening and welcome to another special edition of the Data Services Office Hour. I am Chris Short, host with the most of Red Hat Live Streaming, and I'm joined by the one and only Michelle DiPalma this morning. Michelle, how are things up there in Canada today? Fabulous. Fabulous. Just fabulous. Just fabulous. The weather is beautiful. Everything's great. No, we're gonna have a good show. So I'm excited. I got stuff to show you. Awesome. I'm excited to see this because as we all know, of the idiots in the room, I am the one that's the storage idiot. So yes, I'm curious to see what's new in ODF 48, and you are going to show us is what I hear. Yes. So here I'm going to share my screen. Hang on one second. All right. Can you see everything? Yep. I see everything, everything. Okay. So I'll start with access at redhack.com just so people see how I get to where I'm going. I'm not even logged in actually at this point. So let's go look at the release notes. Always a good place to start for what's new. And I'm not going to go over all of them because I kind of realized. People can read. People can read. People can read. Yes. They can read. They don't read, but they can read. Right. Okay. So 4.8 release notes. I just wanted to point out a few things. We're just gonna do a new feature. So if you go through this document and you look at what the bolded, you'll just get the gist of what it is that's new. I want to, today I want to discuss briefly compact deployment general availability. I'll show you how it's done. Yeah. No compact is really cool actually. Yeah. It's easy. It won't take very long at all just to demonstrate like to show you what I did. And then the one of them is easy. Okay. I did. I'm a shocker, right? The one I want to spend time on is the caching policy for object budget. So if you don't mind, I'm going to spend the bulk of the show talking about and showing you refreshing MCG ideas, multi-cloud object gateway ideas, and then showing specifically how the caching policy gets used because I actually think it's kind of cool. Yeah. This is just a fun stuff show. I've had a fun experience the past few weeks with just web caching in general. And then like it's really kind of opened my world to like there is a lot of edge out there, right? Like trying to make the experience the same for somebody in South Africa as it is for somebody in San Francisco is challenging, right? Yeah. So these caching policies are here to help you get data closer to the edge, I feel like, right? And they require a little thought actually. Yeah. Like some planning and, you know, like classes of storage, yeah. And I'll show you the documentation. I'll go through it and it's good because it's completely accurate. But I thought I could compliment it by having sort of like, okay, if you take the 10,000 foot view, this is why this is set up this way and this is how you think about it and then you can customize for your deployment. So I think I did this last time. The volume encryption. Volume encryption part? Yeah, you showed that off. So there's more as we go down and we can talk about maybe if someone's interested in some of the, I think there's replica two, there's some other stuff going on if we want to do that in a future show. But I think that these two compact and caching are going to take up our time today. Okay. So let me just say real quick, folks, for everybody out there watching, this is an office hour. So if you do have storage questions, ODF or OCS related storage questions, feel free to fire away. But we come with a topic prepared. This is what we're talking about now that does not mean we talk about this the whole time. If you have a question and you need help with something, feel free to ask. I will do my best to answer it. There's a lot to, there's a lot to ODF and a lot of different ways to configure it. So I'm by no means the expert in all of them. But usually we can find the answer. Yeah, exactly. So let me show you something. I wanted to show, so starting with compact, I have this is when you go to install your configuration, there's it's actually right here in the document, wait a second, it's a computer three no cluster. You're told exactly what it is you need to do. Pretty much you're modifying your install dash config file, your YAML file to do this. So do you, I don't know how you, I always install an AWS because it's just what I have access to right now. And I will have a nice massive, I have my golden basic install config YAML. And in here, I will change stuff up according to what I'm doing. So this is my standard ODF. If I know I'm going to deploy ODF because I have to do a demo, I need to try something out. This is what I would typically deploy. We have other instances that we support, but I think I just like put this one in ages ago and I stayed with it. So we have our workers, I'm going to have three of them, they're going to be in five, four largest, and then I have the control plane down here. And that's pretty much it. I could probably make this smaller, maybe, I don't know, but this works. So I stuck with it. The change, just like it says here in the documentation is we're going to take the platform to just brackets and the replicas to zero under worker. So I'm reducing my worker nodes. Okay. So in addition, as you can imagine, I have to make sure that the masters are scheduled. Like if you look down lower, it'll take you through the direction of how to do that. Like so it may not be sufficient to just eliminate your workers. You also have to make sure that you can schedule pods on your masters. So the pods, your master nodes are now going to become collapsed. They're going to have a role of master and worker. So that's just open shift. Like if you're doing compact, that's how that's done. The one thing I wanted to mention to anyone here is let's say you're doing edge compact and you know you want ODF, you need to make sure that your masters are big enough for ODF. So I took a copy of the same file. I'll show you a different a second. I reduced my workers and all I did is I just made my master's figure. But that was really the reason I mentioned this is for the first time I did it, I didn't do this because I I didn't have the forex large and I go in, I'm like, Oh, great. My cluster's up. It's compact. Yay. And then I go to install ODF and I got a little warning when I went to install it. And it was and I'm like, what is this? It was a tech preview pop up. Okay. That said, you're installing with minimal resources. This isn't tech preview. So I just want to be clear. Minimal resources is not compact. No. So let's let's pause for a second there. I have seen a couple articles, a couple slack messages, a couple, you know, readme's out there that have talked about like OKD or even vanilla Kubernetes and like having really, really, really tiny masters and really kind of not much bigger worker nodes or controlled plain nodes and worker nodes. Sorry. Like folks, you have to think about what this cluster is doing the whole time, right? Like if you're throwing metrics at it, if you're throwing, you know, any kind of operators at it, like it's got to be able to handle that workload. And whether they be info nodes, control plain nodes or worker nodes, they can't have 20 gig disks. They need more room than 20 gigs folks. Exactly. I've seen several tutorials this week where it's like, Oh, yeah, all you need is 20 gigs of disk on your master. I'm like, how can you even get IOPS for at CD out of that? Right? Like I don't understand. Like folks, you've got at CD has to perform good and your cluster will perform good. But if you throw too much on your control plane and you don't give it enough resources, it will struggle. Yes. Very bad. Some thought is required, even for compact, right? So think about what you're doing. Think about how large these machines need to be and so on. And I thought it was at first I panicked when I saw the minimal resources and then I remembered I'm like, okay, no, no, no, no. With this setup I have now where the masters are large enough so I can collapse the two roles of master and worker on them. And I go to install ODF. There are no warnings about anything even though it's a compact cluster. Why? Because it actually has the resources it needs. They're just collapsed onto the master. So I just wanted to make that point. If you find yourself going to you install your compact cluster and then you go to install ODF and you see a warning about minimal resources, it means that the masters are not sized large enough. Got it. Right. And if it's this, maybe you can fix it later. Maybe you can go ahead and install it and then just expand capacity later. But if it's like CPU and stuff like that, then you may have to go back and resize. Yeah. If you're lacking CPU or memory resources, you're going to have a bad time. Right. So here's the diff on the two of them. Yeah. Yeah. So really straightforward from platform, it goes from AWS in a 4x large and replicates three, I take it down to nothing zero and the type from underneath the control plane has changed to something much larger. That's it. So what does that look like? So it's a three node cluster now? Or it's still a six cluster, right? No, no. Well, no, but this cluster with two roles. Okay. Yeah. So I actually two clusters up right now. I have my compact cluster because I wanted to show that to you and I also have my regular cluster. But I could do this all on a compact cluster. I just didn't want to complicate my life here. So I'm just going to run it top because I'm having issues these days. All right. So this is what a three node cluster looks like a compact cluster. Nice. Okay. Yeah, I am 5x4. So that's it. And here your roles and here your pods, everything's scheduled. ODF is up on this. I mean, I don't want to mess around with it too much. I mean, as you can see, I'm testing things out, but here, here's stuff is it's ready. It can do anything on three nodes. Wow. Could you do, I mean, this is a personal question almost I feel like, but could you do a compact ODF cluster on a larger open shift cluster? Like if I had like an eight node open shift cluster happened to sit in my basement. But yeah, like I'm kind of curious, can you do a compact install on a larger set of clusters or do we have to have this mixed mode master? So when you, when you go to the part where you go to create the storage cluster, you get choices there, right? So you, you could decide to pick the smaller nodes in your setup, you actually do get some, some choices. If you want to do minimal resources, though, it's still tech preview. You can do it, but it's tech preview. And it's actually, I think it's in, it should be in the release stock as well as further down it talks about tech preview, dev preview. So you can try it out. And also something else that's available in this release, but I wasn't going to do today, but we can do a feature show is you can turn off different components. So if you, if you want to run super small, you can say, you know, no MCG and I think, no stuff. So like there are certain components, you can just say, don't, when you go to create the storage cluster, you turn them off and you're running with the minimal things you need to have Rookset. And in other cases, you can also turn off Rookset and just run MCG. So there's more, lots more flexibility coming for, and I think it's probably driven by the edge cases, right? Well, you need to choose what you want. So this is what a compact cluster looks like with OD, the difference from the ODF side is you don't even know. I don't think you would know if I didn't. Well, and yeah, you don't see it. You don't see anything different at all. It looks the same to me. That's pretty awesome. So that was the compact thing. I'm sure there's more to talk about there, but that's pretty much my knowledge of compact. I haven't done more than that. But just the fact that you can get open shifts and ODF and three nodes, that's a big one for everybody, I feel like, right? And there's more about it here. It's living with three-note architecture. Yeah, I dropped those links in chat for everybody to see just in case. I don't know if I'm okay. All right, so the meat and potatoes of today, and I know when we get a little bit here, but it's actually, I think it's pretty cool and it's a big deal. We should talk about it. All right, so caching policy for object buckets. So let's back up for a second here. Let me get rid of this one. So this link here takes you, where is it? That one takes right to chapter nine about caching policy project. But I, well, we have to back up because I'm sure no one remembers what they need to remember about MCG. Do you remember about data federation? It was a long time ago. This was a long time ago. I'm gonna go, like, I'm actually pulling up the open shift YouTube page right now to see if I can go find the episode, but it's been a while. Okay, so let's back up for a second. I'm gonna close, this is my regular, hang on, let me just close this so I don't confuse myself. Here we go. All right, so here's my regular, this is a normal cluster, right? Not compact. And I installed open shifts, container storage, everything's up to date. And I'm fresh. I'm new. I haven't done anything other than this. So what I wanted to talk about was the backing store, the namespace store and bucket classes to complement what you're going to see in the documentation. So just to refresh for everyone, the multi-cloud object gateway is a gateway. It is not an object store itself. It's going to use other object stores and create virtualized buckets that achieve different goals. It sets policy on them and so on. So whether you're talking about the regular standard MCG bucket, which would be when you mirror between several buckets or you tear across, you have like levels and you can mirror, you can spread, it does the duplication and all that other stuff, that's one kind of standard MCG bucket. There's also namespace buckets, which is what we talked about in data federation, which are exactly what they sound like. So just like with database federation, you would have, you have multiple buckets and you say, I want to read, I'm going to create a virtual bucket and I'm going to read from these buckets and I'm going to read them right to that one. But the buckets themselves may have information in them already. They can be accessed the way they've always been accessed. So I mean, really namespace buckets are just like data federation for databases, right? So you generate across the both. Yeah. So it's, so it just, there's a reason things get named the way they do. And I think it's just important to, naming's hard. So in the case of MCG, because it's not an object store, it needs other stores. The standard bucket, it needs, so this is where this naming comes in. A backing store backs up a standard bucket and MCG. A namespace store backs up a namespace bucket and MCG. So the naming will start to make sense as we go through it, but you, it comes with a default one. We installed this one for you. Cool. And just, just like, as you can imagine with data federation or as well, when you go into your backing store, what are you going to need? Remember, MCG is a gateway. It's not an object store. So it needs what? It needs to know the provider and maybe some details about the provider. It's going to need credentials to connect and it's really going to need, what's the target bucket? The target bucket. So I can create another one. So this is, this is the default one that comes with it, but I can create another one that has Azure as a provider. And these are all, so when you do object bucket claims and stuff like that, you can have these backing, different backing stores. So, but a store, whether it's backing or namespace, is always going to have provider, credentials, and a target bucket minimum. And I, and I know, looking at your screen, I see S3 compatible, which means you could just have a, a Minio instance pointing out a huge J-Bot if you wanted, you know, like the sky's the limit here. Yeah. So going back to the multi-cloud. So, so when, if you're just setting up one store, you don't need all of this, right? You wouldn't do it this way, but that's not the point. The point is to have more than one and be the gateway to more than one. So I'm going to, I'm going to use the default backing store in this one, but I wanted to show you also under namespace stores, when we go to create them, they're the, they're the same. The information required for data federation is the same. The difference is in how it's used. So it, just like in databases, if I'm setting up a federated table, I don't want to mess with the original table. That's not the point. I just want to view, I want to view into them. So as opposed to if I were setting up an actual table, I would be messing with it. So it's the same case here. When you have namespace stores, you're saying, are we going to have read into this? Great. Giving my credentials, giving my provider the information you need is the same, but it's not, they're actually not going to write to it unless we say so. And that is setting policy. So I'll show you that. So the reason we have the, it's just to set up these different names. So I'll set one of these up for you now. Let's call it, I have, and actually what I should do, I realized my naming was not so bad. AWS, this is going to have a particular bucket. So I like to name it, not the standard. Let's do the Mdapoma bucket. Okay. Make sense. Just so you know, yeah. And think about it. Like you really, red crumbs are great folks. Absolutely. I've already put the secret in as AWS secret. Yeah, you would have had you to get the other one, right? And then this one, I want my Mdapoma bucket in Mdapoma bucket. There is, there's already information, right? I have some images from my previous demo. So this is a case where I'm not, I don't want MCG to go in and take over the whole bucket and all that. I just want to read what's in it, right? And I might have more than one of these. So I would consume the bucket. Yeah. I want to consume the bucket, but I don't want to hear about that new world daily. So this is another bucket. We'll add this one in as well. So that has to be, so as I do this, that was Mdapoma bucket. Secret region. Yep. Yep. Yep. Yep. I've got all this. I've got one for Azure Hang on. Let's do silly question. Yep. Maybe not silly. Why SSL disabled by default? Oh, I don't know. That's a good question. I mean, it works for me. Right. Like I'll dig into that because if you, me personally being the person that I am with the background that I have, I think all traffic should be encrypted over the internet, but that's just me. Might not be the case for everybody. So I was going to let's just call this Azure bucket. I can't remember which one, but it'll pop up down here. Hang on a second. I select my secret that I already put in in here. It's 12. I just happen to remember that. So obviously naming properly. I'm not here. Azure bucket 12. Let's do that. So I know that. There we go. You know where it's coming from. I know the bucket it is. I'm all organized in my virtual world here. So if I look here now, I'm under namespace stores. I've got two. So these point directly to two buckets. It contains all the credentials and information I need to connect to those two buckets. They're just stores. These are the actual object stores that are going to be connected to. That's it for this type. We haven't done anything other than set it up. So in bucket class. Hang on a second here. I'm going to have to hide here for a second. Okay. In bucket class, we get to start to see how we're going to separate between standard buckets and namespace buckets. So we're ignoring the default for now because okay. So what's the bucket class? So here we go. This is like the meat of MCG. It is though. So standard buckets in MCG are kind of what we discussed before, which were I'll show you in here. Every time you go into bucket class, you're going to do the general what category is it in? Place and policy and the resources you want. So let's just go with this one for a second. If I go into place and policy, I remember I selected standard. Here's where I get to choose. How much cheering do I want? What's going to happen in that hearing? Okay. So I can say spread. Great. Let's pretend I'm going to do a spread. And after that, it makes me select the resources. Right now for a standard bucket, I only have one default backing store. I can go add more. Sure. If we can go back and add more, I can do that. Look, it even has it here. Create a backing store. Oh, wow. You just went up right there. Smart UI. I love our team. If I can remember. I don't know, backing store, something. Backing store stream. Yeah, there you go. Yeah. So, and then we use the same secret as before because I'm going to, and then I'll choose a different bucket. Let's do, I don't know. I saw a bucket. Eight and seven in there. Yeah. Where am I? Some other bucket. Oops. Sorry. Let me go back. Some other bucket. Obviously. Yeah. Bucket. Seven. Oh, okay. Let's do seven. If I have trouble, we'll know. Okay. So I've created another backing store. So see how they pop up here and I can choose them. So I can say between backing store and the pama and the default backing store, do a spread. I can go back and say, no, no, no, do a mirror. Whatever, whatever, whatever we want to do. But I have to, I select them and life goes on. So I'm not actually going to do it. Just for folks that are, you know, not at the speed, difference between spread and mirror. Okay. So let's go back here, placing policy. All right. So there actually are some really nice demos about the details, how SCG does spreading and mirroring and duplication and all that kind of cool stuff using crush algorithms or whatever. Like, if they get into it, much, oh, it's like deep. Okay. Got it. Yeah. Right. But just at a high level, spread places, the data everywhere, so that you can recreate it no matter what failure domain you're trying to hit. Correct. With all kinds of like error checking and so on and so on. And mirrors, just that mirror would be a mirror. So you could, I mean, we tend to think of mirror as just two, but if you have five, you can do that too. And also your second tier can be something else. You don't have to keep them the same. You can have a mirror as paranoid as you need to be. I think of it. I'm like, how paranoid are you? So that's the idea here. So in this case, everything with MCG is encrypted in transit, but everything written out is encrypted as well. So if when I go to create this, if I went to look at it just with like through AWS and look at it, I wouldn't be able to read it because it's all encrypted. Got it. All right. So Rapskating Reef says in chat, it sounds like spread is RAID 0, where mirror is RAID 1. Does that make sense? Yeah, but I think there's more. And actually we can do, yeah, there's error checking and blocking and all that. Yeah, I get it. But yeah, I would like to get someone, maybe the developers who work on it to actually speak to it because I'm not going to do it just like there's more going on, but I'm not going to be able to like really explain it well. So if you're doing spread and mirror, you're basically doing kind of like a RAID 10 scenario, essentially like you're striping and you're mirroring data replications everywhere. Yeah, cool. So remember, this kind of bucket in MCG is often used when the business policy of a company requires encryption in transit and on and at rest. So you know, this is where it typically comes up where it's like, oh, it's object and it's got to be the zero requirements. So okay, we'll just do it like this. Any other questions about this? Because I want to hear this. That was a great one, Rapskating. Thank you. Yeah. Okay. So yeah, so this is like standard kind of spread mirroring as you were saying. We choose our resources here. We can have as many as we want to configure each one of them and up in the buckets, right? And so on. But there is a question. Sorry. So good. What's the difference between spreading then mirroring versus mirroring and spreading? Is it just an order of operations thing or is it? I believe it is. But so I've had the same question. I'm like, why, what are the scenarios where I want to do that? That is a question I have not answered yet. Like what, right? Like, yeah. No, like when do I spread and mirror versus mirror than spreading? That is a good question. Right. So I don't have an answer for you because I have the same question and I will, I will chase it down because I should know that. Great question. Great. Excellent. Yeah. Thank you. Okay. So while standard bucket classes are in your fresh in your mind, I want to compare them to namespaces because this is not what you just saw, even though placement policy and resources and the review are all of the same. So in the case of namespaces, we have data in the buckets already. And we have to go and configure a bunch of interesting things about this. This is Federation. So if you look at placement policy for a namespace bucket, you get a few choices. So we're choosing a policy here and let's go through them. The new one in the UIS hash namespace store, which we'll end with that. But so cool. So a single namespace store. So there are different scenarios where you would choose different ones. So the one I normally work with is this one, the multi namespace store. But there could be cases where single might be very useful too. So again, MCG is not an object store. It's going to be a gateway to an object store. So if I have a single namespace store, single namespace store, it's going to be, I choose, I haven't created any, I choose one. But these are careful. These are namespace stores. And we did create them. So I'm not going to, so these have data in them. Right. Right. This one was in Azure. This one was in Mdapama. I'm not going to necessarily write to them. We have to see where, if I'm in single, I will. So who goes next? Okay. So in this particular case, I didn't name it yet. I have to go back. I have to give it a name. Let's call it bucket class single. Right. And we go next. I choose it the single namespace store. I'm the back ending. I shouldn't use the word back because it's used under source. The namespace store that's going to be used, we have chosen as AWS Mdapama bucket, which when we look here, we can see has stuff in it. Yep. Okay. Just so we're clear. And then, but notice I don't get them. I don't get a choice of many. That would be the multi namespace. Right. You can select multiples. You can only do one. Got it. So, so what? Here we go. So I just created this one. It's available. If I want to make an object if I can claim on it, it's all there. Remember, I'm creating this bucket class for it. So this could be, I happen to do one in AWS, but we can do one in Azure. So you can, you create, this is when you have a case where you have some bucket somewhere that's got to be read only or excuse me, you want to be able to read the existing data from it. Right. And you're going to write to it as well. So you're just giving it one. There are cases where you may just want to have this kind of federation with one. I don't typically use them. I typically do multi or now I'm going to do caching stuff, but there could be situations where that is, if you think in terms of federation, you want to be able to offer all of that. So that was single multi, but how did I name them? Multi bucket class. Thank you. Yeah. So multi. Let's do this one. Okay. Okay. So I'm going to choose multi. And now I get to choose more. So I can do this. Nice. Right. And this is kind of like straight up federation, what we were doing before. So I have, I've chosen where I'm going to read from, which could be many, many, and now I'm going to choose which one I'm going to write to. So I can, it doesn't matter. Okay. And then we review it and we go off. So this is a very simple case, obviously, but I could totally see regional areas, right? Like I used to work at a newspaper company and we would get photos from people all the time. If I set up FTP servers for these photographers or SFTP servers back then, across the globe that tied to a bucket, I could just read in all the stuff into my, you know, CMS and just be like, all right, optimize images, optimize images and store, you know, locally so it can get uploaded to our CDN done. And that would be brilliant. That would be, so hang on, let's see if I mess up my AWS creds. No, no, not my Azure creds. Oh, your Azure creds. Yeah, right there. So I bet you I did. So let's go take a look, B-Class Mopey and it's a bucket class. Hang on a second. I'm sure. Okay, so I'm on the right place and my projects. There we go. Okay, so let's see. Okay. B-Class Mopey. Let's see. Is it, that's why is it having trouble? My Azure bucket 12 is not yet ready. Maybe. Temporary error status false. Temporary error. That's me. Like it means I did not enter something properly. Like that's probably what it is. Yeah. All right, so can I go to my portal? Do you actually want to do this on screen? Do you want to turn your screen off for a second? I might actually be in there already, but hang on. Let me go check it. I will go check it. I probably I don't want you sharing creds on air. You're totally good. The other thing I was saying, I'm stopping my share. Give me two seconds to just make sure I did the right thing. I probably made it up and I'm not actually in a bucket that exists or something like that. All right. I have to sign in at eight, nine. Probably. Yeah. Like it's always, the process works fine. It's always like I, it's me. That's what I have learned. Storage is hard. I mean, let's be honest here. It's not trivial. That's why there's a show, a whole series on the channel about it, right? The whole series. I think you bucket 12. Okay. So let me go in and modify this. I should probably be able to share now. Hang on. I have to find you again. Here you are. Okay. I'll put you up here. Do you see it here? Okay. Azure bucket 12. Do you see my screen? All right. So that Azure bucket row is the right resource. So I have to go back to my namespace store and look at this one. Let's go modify it. So that's, yeah. No, it should have been like 12. I bet you might credit my secret. Scroll down for status message there. Account key. It doesn't exist. Yeah. All right. I have to go off screen and fix it. So you guys can see my, give me a second. Okay. Privacy please. Privacy please. Hang on. Hang on. This is my Azure secret, right? Okay. Account key, account name. Let's see what I did around here. So while you're doing that. Yeah. Ignore me for a second. You do you. You could even mute me if you wanted. So folks coming up later on the channel today, we have a bunch of afternoon shows for me at least afternoon. At two, we'll be sitting down with Wei Ling Dang. He's the co-founder of Stack Rocks. And so this is at 2pm Eastern 1800 UTC. It'll be on all the YouTubes for you to watch later if you're in Europe. I'm sorry. It doesn't align with your time zone, but you can watch it on demand on YouTube. But we're going to talk about like a lot. We're going to cover the gamut of, you know, how Stack Rocks was created all the way over to, you know, what Wei is doing now inside the organization with ACS and all the fun stuff we're doing there. And then after that, immediately after that, we're going to be revisiting Arbeck on the Get Offs Guide to the Galaxy. So Arbeck is hard. And I always encourage you to go and watch Arbeck videos because that's where you're going to run into your like, oh no, massive security hole. Whoops, because I didn't understand this one thing right. And so we're going to revisit a previous episode and kind of continue on that. Meanwhile, back here on the data services office hour, we are ready to go. Yes, he's ready. Done. I'm ready. So just so you know, the secret I created for Azure was I had the field names that you use for AWS. The error we had actually says, account key, account name, which is correct for Azure. So this is now ready. Everything about it is ready. So if we go in here, we can scroll down. Yep. Yep. Yep. We can scroll down. Yeah, look at everything done. Yep. Yep. Everything's happy. So back to you. Okay. So at this point, we're all set up. So wait. So the final ones, we've got a single, we've got a multi and this is a standard default, which is not federated at all. So let's go back in the namespace. This is going to be cash. There we go. Next. All right. Cash namespace store. This is what's really, really new. So this is why I wanted to build that. The caching bucket will serve data from large, from a large raw data out of a local caching tiering. But that needs some English work. It needs some explanation. So you would use this kind of MCG federated bucket in the following scenarios. You have far away. You have a massive amount of object data in some buckets. Yeah. I'm on the West coast of the US, but I've got to take all my EU data way or yonder. Yeah. And you want to do caching near MCG, near where the gateway is actually running. Mm-hmm. Multiple clusters, is that kind of thing? Yeah, yeah, yeah. Regional clusters, yeah. Yeah. And you want to be able to control where that caching goes. Yes. So that would be, I imagine, so in my mind, I always think of it like, okay, let's say you've got some special, you know, fast storage, you create a backing store on it. Local to MCG, where you're running, maybe it's compact, right? You can see how narrowly you've got low compact. Yeah. I could always see a compact data store in each major region or whatever it is. And maybe you're not using that for the rest of your ODF install, but for this particular case where you need to cache, and it needs to be super fast, you want that to be here. Well, we didn't, we only use the default in this demo, but you can imagine, you can have many backing stores, and that's for regular normal MCG buckets. But here we're going to use a regular normal MCG bucket as our local cache. We're going to fetch from afar and then do it. So it's about control. Like this is the control. Yeah. So over here, remember, so hub namespace store, what's my far away bucket? How do we get to choose one in this case? Like I'm like, because it's going to be some large set of data in one area that I want to bring closer. Let's do, let's see if our Azure bucket works, it should. And then, so I set that, I said, what is my namespace store far away? And well, where am I going to write to it locally? Well, I think I created this one with AWS, but I can use my default as well. So one is a namespace store, but my local cache is a backing store. Right. That makes sense. No, that makes sense. But like that default backing store, what, what is it using? AWS, in this case is AWS. In this case is AWS? Okay. Yeah. So the default, and it's not going to correct me if I'm wrong, but I believe the default backing store for MCG will depend on where you deploy. So if you're on-prem, it will actually use Rookstep RGW. If you're on VMware, yes, it'll do that as well. But if you're, if you have a deployment in Azure, it will be there. If you're going to be in AWS, it just defaults to an AWS store and it creates it, creates the bucket, it talks to and everything. But you have control now. It doesn't have to be that if you don't want it to be. So I see this as very useful for hybrid cloud, right? You're on-prem. You got data far away either, I don't know, some other part of the planet. You need to have a view into it. You don't need all of it. You want to cache some of it locally, but you want to ensure that the cache you're using is nice and fast and you want MCG to do it for you. So there you go. So you get to set your time to live, right? Which you wouldn't normally do in the cache. And then voila, you create it. But the thing that's, the nuance here is that the hub, the far away part is federated. So it has to be a namespace store. The cache, which is close to the gateway, has to be a backing store. It has to be a normal backing store for MCG. So I wasn't sure if, if that was entirely clear to everybody looking at it, you may be like, what, why do I have to do this? So I just wanted to make sure like that's the mindset. And now you can think of different scenarios where you would use it, right? So this is one of those scenarios where it's like, I kind of want a picture, right? Like, yeah, like, I feel like we could have like flash cards almost of read many, you know, right? And which, and which scenario goes with like, why would you write, why would I use XYZ kind of thing? Yeah, correct. Correct. You're right. So, and just to complete this, if I go into object bucket claims and I make stuff, I can, I can do, you know, let's do a single, just to stay with naming it bucket single, right? And I can choose something here. I go into that's my storage class. And then I choose for my bucket class, which one I want. So you see how we're, so the object bucket claim chooses a storage class, which has to be Nuba. And then inside of the, after that, I get to choose the bucket class I want. If I choose single, it's going to look, it's going to use exactly what we configured, which I have to go back and look because I don't remember, but there. Done. So if we go here, does it give the information here? No, no, this is all related to we have to actually go into it. So that was single. I've just created a few questions, questions, questions, questions. No questions. No questions. Yeah. So here we go. Here comes the next one. We'll do a multi. Nice. Yeah, just just to show you. And then we can go. So here you start to see them look and it tells you the secret it's using. So you can see how important your name is going to get, right? So that you should be able to look at this at a glance and say, oh, I know, I know what you're doing here with kind of stuff. So hang on. So let's just do the last one. More useful than bucket cash. I hope people do. And off we go. So, so that the caching part is the new feature. Sorry, I said that wrong. Having the cash available to you in this bucket class UI is in a feature. There was caching before, but you couldn't, it wasn't quite like this. You couldn't necessarily configure it as granularly as you could now. Right, right. So I think what would be, and I'll probably follow up with this, some diagrams explaining like when you have the following scenario, this is where you would use, you know, single namespace bucket and so on. But it's sort of, it has some nuance to it. And I think for the caching one, I mean, I can see that being incredibly useful in edge cases. Right. You got a little little cluster. That was my thought. That's useful on edge. And then you're doing your work there right at the edge, right? You're bringing in the data you need, hot cash, you work with it and then you write it back. So so those are the big what's new. Any compact questions? I don't know. Do we cover everything we wanted to cover in compact? I don't know. Folks out there, if you have questions about compact, let us know. I feel like you did a pretty good job there. Okay. And then so everything I did is in the documentation. A lot of it, you can do all of this from the CLI. It just, I wanted to show off the UI and it also looks better during demo. So this chapter I'm in here is managing hybrid and multi-cloud resources for those who are interested if you want to see more about all about MCG, how we do all of the different parts and what have you. So but I, the one that's coming out of release notes is chapter nine, caching policy for object buckets. But again, if you're looking into it and you don't understand it, go go back and look at the the supporting documentation for how to use MCG because once you have that in your head, I think it all kind of flows from there. So there we go. Want to create, we can create more stuff. We can look at some of the other stuff in the release notes. Yeah. What else, what else is in here? I'm curious. There's a ton of stuff in there's so much like it's, yeah, I mean, that's our new features. Okay. We did compact, we've done caching policy. We've already done versus long encryption, thick provision stuff. Okay, you have to talk to Chris Blum about that guy. The thick provision for VMware is a whole like thing. Yeah, it's a whole thing. Right. So as, and I would, I would like to do some of the other things here, like for idea power systems that I right now, I don't have access to this kind of lab. So maybe in the future, we can do some stuff on that. But let's see, air gap stuff, enhancements, we've got some new alerts that come out. I would like to do replica two at some points for you. That would be fun. It's in here somewhere. Hang on. Do a fine. Oh, hey, hang on once again, compression decompression. Yeah, yeah. So we did this too. Added the ability to create names to fuck it using the user interface. Tech previews are always interesting. Multis, it's fair. That would be an entire show and a half. Well, yeah, I mean, we should do a multis show to be honest with you. Not necessarily just you, but I could bring in the expert from my team on multis and we could do a collab show. That would be cool. We could do a collab show. And then if they do the multis part, then we should be able to set up so that all of the storage talking goes over this segmenting network. So that would be awesome, actually. That would be, and I think, and there are already customers who do that and what, and there are a bunch of others who want to do it and know they have to do it because of that. So what else is going on? I think there was a component. I was looking for the, I know it's here, flexibility. So this is going to be really interesting also for Edge, right? This idea here that you can turn things on and off, turn off our RGWO, turn it on and so on. I would like to test that out on it. We could do like a super duper minimal ODF on a super, super tiny edge cluster and see how well that works. Run some performance testing. We could do that on your cluster. That's true. We could. Maybe we could do it right, like see how small can we get and still have what we consider reasonable performance and just turn off pieces you don't need. I would love that. Yeah, that would be a cool show. Yeah, I would like to set up first, obviously. I mean, we could pull up my cluster right now if you want and walk through it, but we only have 15 minutes. I know. So like, so I, yeah, when I was thinking about like, what else am I going to show? Like, these things are really big. So, and it's fine, right? Like, if we end early, that's okay. Just as long as we answer people's questions and share more later, we're fine. So yeah, like flexibility and sizing, that's cool. I like that. Yeah. Yeah. And being able to really fine tune what you want on your edge cluster is very, is really important. So, and then, yeah, so I would think of like small edge cluster, very, very minimal footprint for ODF, and then you can even just, you have MCG and you're just like caching locally what you need on something very fast, right? And you do your work there, and then you send it back or something like that is just more flexibility is better. So that's kind of what I have. That's great. No, this is very informative. I mean, we got questions, we got, you know, some curiosity we need, we realize that we need to kind of, you know, maybe have six or seven slides that say, hey, this is when you would want to do these certain scenarios, right? Like, I think that would make for a great blog post, a great live stream, a great everything, right? Like, you could write the blog post, and we could just go over it on air potentially, you know, and kind of demonstrate and show off how to build the various things in the blog post. We could also do a more in-depth explanation of how spread and mirroring is done inside of MCG. We've done before, we could do that. Like, if we get some of this, who wrote it? I wouldn't talk about it, that would be fine. And then maybe we can also talk about caching and what's going on there as well, like how that's all being managed internally. That would be interesting to have someone go through. So, bring to it. Cool. Awesome. Any new questions? Anyone? We didn't come up with a poll. No, but I do need to give you access to the thing that can give you polling. So, we can do polls later. I think actually, yeah, you might already have it, but I feel like I've shared that with you before. But anyways, maybe I didn't. I've shared a lot lately just trying not to be a single point of failure. So, we'll see. But yeah, let's definitely talk for a few minutes after. And folks, if you have any questions, feel free to reach out to me at ChrisShort on Twitter. My DMs are open, short at redhat.com. My email is open, and I can get any kind of question you need answered. Trust me, I have ways. I ask nicely. That's the way. That's the way. Works for me. Ask nicely. Right. All right. So, thank you very much, Michelle. This was great. I'm glad we went over all this stuff because like the tiering, that fascinates me, right? Like bringing data closer to people in compact clusters based off of region or geography or data center therein. Yeah. That's going to change some folks' world, and that'll be awesome. So, thank you very much for showing us that. Thank you. Thanks for coming, Evan. Yeah. Thank you for coming, and have a great day. If I don't see you again later today, stay safe out there, folks.