 Let's get into the big topic of open source, something that we actually have in mind. This is so awesome. We are an open culture that is actually a place that process that a developer or, let's say, as the Kubernetes ecosystem really brings. Good morning, good afternoon, good evening, wherever you might be. You find yourself, once again, with the level up hour. And we have a really great episode this week. We're going to be talking about dynamic console plugins for OpenShift. Have you ever wanted to customize your console in OpenShift? Apparently, if you have, you've got a lot of company. And to talk us through that, we have my co-host, Jafar Traivi. And we also have a guest. We have Serena Nichols, who is the Senior Principal Product Manager and Distinguished Engineer for the OpenShift Developer Experience. And so welcome, Serena. Greetings, Jafar. Again, everybody likes, subscribes, and shares so that people know we're here. And Jafar, I think maybe the best way for us to get across what we're talking about here would be to go all in from the start and do a demo. What do you think? Yeah, that sounds like a good idea. So let me share my screen. What could possibly go wrong? Get started. Exactly, yeah. All right. So I see you can see my screen. So I've been a fan of the OpenShift console for many, many years. And it does bring a very nice user experience on top of Kubernetes and OpenShift. But one of the things that I always wanted was to really be able to push it even further and have some custom things appear on the console. So I've been creating some web apps for OpenShift and stuff like that. And finally, we have a way to bring whatever content we want into OpenShift. And Serena will walk us a bit more through how things got there. So here I have my OpenShift console, as you can see, the administrator perspective. These are the traditional tabs that we know. But here you can see I have something called My Custom Plugins, which is something that I added a few days ago. And basically I can put in there new links that take us to whatever content we want to put in there. So here, for instance, I have had a crazy idea of having like a 360 view of my current application and basically go to ArgoCity, pull content from there, and also go to GitHub and maybe pull some GitHub issues regarding the application, et cetera. So as you can see here, this is directly integrating the GitHub API and putting data and surfacing that data into the OpenShift console in that section. I have another example. So all of these are just crazy ideas that came out of my brain, but basically you can do whatever you want. So here, for instance, we have an ACS security tab. And basically for the current images, it's going to pull the security results from our ACS tool, the Advanced Cluster Security for Kubernetes, which does provide security scans and a lot more features on top of that. And surface those results in the OpenShift namespace or in the OpenShift console here. So that's a second plugin. And a third example, which is closer to something that I've been hearing customers wanting to do, which is basically, how do I onboard my developers with our custom content? So basically, we have our documentation. You're a Java developer or you're a Node developer, but you don't really know where to start. And we wanted to have some guided walkthrough of this is how you start. So go read these things first and get familiar with our way of developing our applications and deploying them, et cetera. So we had this crazy idea where we would come up with something that is called, I would say, design patterns. This is more general than that. But basically, we said, what if we can document our content somewhere? So and that somewhere here is in GitHub and come up with like a structured approach where basically we say, this is the title of our pattern of our guided walkthrough. We have an overall description. We have an architecture. And we have like a nice architecture diagram. What if we could could surface that into OpenShift UI itself in a dynamic way? And that's basically what happens when we go here. So I have those patterns that appear in the console. And this is live data from GitHub. So basically, this plugin pulls the content from GitHub and shows it here. And when I go into the details of a specific pattern, it transforms what you see here in Markdown into a guided approach where I see basically I have the overview, then I go to the architecture, the guiding principles, and then the architecture diagram. So basically, our customers can use a similar approach where they document all the developer onboarding. And they say, so first you do this, and then you read this diagram, and then you go to this wiki page, et cetera. But instead of having all of that content outside of OpenShift, it can now land inside. It's easier to access, and it can be interactive. So next step here, for example, if we have anything that we want to deploy, we can imagine that we have a deploy to OpenShift button here. And so I already started crafting some stuff like that. And it's going to, as soon as you hit the finish button, it's going to deploy whatever assets you had for that guided approach into the OpenShift namespaces. So it makes it even more interactive, and it's not just documentation. It can be something that actually does things within OpenShift itself. So just to verify, this is allowing, you created the plugin. Now anybody can go into that Git repo. Yeah. Which is there, and it's going to update here, right? So like. Exactly. And so just to show you that, so let's try that actually. So I'm going to create a new file, but I'm going to get the content first from one of those patterns here. And I'm going to add a new pattern that we will call the level up hour. Okay. And we will call it levelup.md and put our content in there. But instead of this supply chain, we will call it the level up. Our pattern, for instance. And commit our changes there. So now we have six patterns. And let's try to reload actually the page and see what happens. So of course, this is a POC, so it still needs some like improvement in terms of performance, but there it is. I already have my new pattern that has been pulled from GitHub. And if I go there, I get whatever sections I put in there. So very easy way to document your approach and have that lively surface into the OpenShift console. Well, so I love this particular demo here because, you know, you think about OpenShift as your plumbing essentially, right? But and then the having the documentation live somewhere else now means there's two places that somebody that you're trying to onboard has to understand and use. And so now the documentation lives inside the plumbing. But in fact, the documentation is actually part of the plumbing. So this is this is actually a really interesting thing from a sort of a management perspective because it is a means by which you can get everybody on the same page, that there's conventions that everybody follows and you're making it easy for people to do the thing you want them to do. And for it to be clear about how they're supposed to be working here. And so it's a great example. And so I guess I'm sort of curious more broadly about what are some of the other kinds of things that that are getting used here with dynamic plugins. Yeah, sure. So I'm going to stop sharing my screen here and hopefully Serena can give us a more, I would say, background on how these things happened. And yeah, yeah, I can go into just a quick bit of history as to why we started with the dynamic plug and piece. If we if we think back to OpenShift 3, right, there was a lot of demand for customization of the console itself. And what we ended up saying was oftentimes customers would really want to customize it so badly that they would they would do it even if there was not a supported way to do so. They would do it in an unsupported way. And what would happen is the next release, there was issues because those capabilities were no longer there. We had changed things. So I want to say maybe in 2019, Ali Moberg is my counterpart. He's the product manager for the OpenShift console on the admin side. And was one of the initial people who really wanted to push dynamic plugins. So we started talking back then about what we could do for customization story or extension story. And at that point, we talked about having the ability for CRDs, which is static customization of pre-identified areas of the console. And then we talked about having OLM descriptors, which is the metadata driven UI generation for OLM pieces. And then at that point, we were talking about having Red Hat Native plugins, which were considered static plugins, which allowed us to have plugins inside of the console for our own operators. So you've seen that today or pre-410 with pieces like OpenShift Serverless or OpenShift Pipelines, where those operators are installed. And we would extend or unlock pieces of the UI or experiences in the UI for those operators, which was great. But then what we saw, we saw a couple of things internally, was that as Serverless or Pipelines operator was released, it was not at the same cadence as the OpenShift console was released. So we didn't always, we couldn't always take advantage of the new features of an operator because it was a static plugin that lived inside of the console. So then we started thinking about dynamic plugins. How could we do that? And there's a great team of engineers who helped work on this. And this really opens the door for internal Red Hat products and features, but also for our ISVs and customers to take advantage of this, right? So in 410, this is really the place where we're saying, hey, customers, this is now available. We still have a limited set of customizations, I would say, but we think they're fairly strong. It's definitely a valid set. We are looking for input to see, hey, if you have some use cases that we don't know about, please contact myself or Ali Mogram. And we can put some things on the backlog. But that's kind of how we got here. I think I am typically talking to customers more around the developer side. And what I hear very frequently is that people want a developer portal, a single pane of glass that they go for everything, whether it's there, like Javar was showing, they're onboarding all of their resources, any tools that they need to get to, and how could they do that? And we really see dynamic plugins as a really great resource for customers to be able to customize the console, as well as in a supported manner, right? So they can use those customizations. It's almost like your IDE writ large. It's like OpenShift plus every other asset you potentially need as a developer working in this environment could potentially be there, right? Or at least that would be the ambition. Yeah, that's absolutely true. And I used to call it the 360 view of our SDLC, the software developer lifecycle, where basically you can pull data from your issues, from your tests, from your pipelines, from your, you know, whatever information from your user stories, from your Git repo in terms of Git commits to know what exactly has been pushed, etc. So yeah, you can be, I mean, the imagination is the limit there, where basically what's the data that you need to be efficient as a developer, and then just pull the data together and surface it to your users. There's a couple other things I think that I kind of need to is that since our console is utilizing pattern fly, right? You know, a lot of what I saw you do, you look like you were using the pattern fly wizard, for example. So if you're using the customization points and use pattern flights, another way to keep that single pane of glass looking consistent throughout the product, which is great. So yeah, we definitely that like some of those are some of our suggestions, right, use the pattern fly components as well. We're also introducing the dark mode in 4.11. And so if you're using those pattern fly components, and if you're not overwriting CSS, you would also with your customizations, if you're using the our typical components, you'd also get that support for when you that change back and forth from light to dark, to be supported without extra work. Yeah, yeah, I found those components really, really useful, because you don't have to basically recreate your own UI components. And it still looks exactly the same as the console, because those are the components we use natively for our development. So yeah, one of the things I liked also is all of the primitives we provide in terms of SDK. So for instance, if you want to show things like pods or services or whatever, Kubernetes resources you have in OpenShift, the console plugin provides an SDK that allows you to say, give me all the pods, give me all the services in a two liner, and you don't have to write crazy API queries to OpenShift to get that data. So there are like very nice accelerators that you can use. We have also reusable components like I want to display this type of items in a list. And then you just use that component. So those are all React based components. And it makes it very easy to get the data from OpenShift and structure it in a nice way in the UI. So you showed a really interesting one where you if I'm not mistaken, you added a navigation item that had children, so sub now items inside of the admins perspective, right? We also want to make sure people realize that they can also do that in the developer perspective. We can also create their own perspective. So they have like a unique perspective that they want to provide for people. That's also really cool, right? Because that one thing that we do here around OpenShift console today is like, other than a cluster admin, why would I go to dev versus admin, right? And like what's there? And I'm just missing one page here or one page there. And how do I combine that? This is really a nice way again to create a customized nav item. I'm sorry, a customized perspective that might be for like DevOps or DevSecOps or something like that. If you really have specific use cases that you want to have just for specific users. Yeah. That's to me, it really opens up new perspectives. Yeah. So you can combine data from different sources, either from OpenShift or even from external tools. And it makes it really accessible. And I think we can also do crazy things like when you right click on the developer console, you have a new action items that you can create and then they take you to a specific custom page that you have created. So it can really become a very customized experience on top of the console, except that those things are not within the console code. They leave a sign and they are loaded on demand when we activate the plugins. Do you want to talk a little bit about that a little bit? How do you activate your plugin? Do you have to create an operator to do that? Do you want to talk a little bit about that? Yeah. Sure. So maybe we can have a look at some code samples before. So it will make it easier to even follow the conversation. So let me re-share my screen. All right. So this page here is so we do provide a GitHub repo that you can use as a starter to create your own plugins. And again, the goal is to make anyone be able to create his own plugin very easily. So keep in mind that I'm absolutely not a developer. I don't know anything about React except what I learned by reading some documentation and stuff like that. So I don't consider myself as a developer. And I've been able to create those plugins in a few days, even a few hours for some of them. So we do provide that GitHub repo that allows you to build your plugin on top of that. And the way it works is basically, so it's React.js code. So you are going to design components. And here to get started, we have an example page. So basically it says we are going to create a component called example page. And whenever we load that plugin, it's going to load that HTML code in the main page that you are displaying. So very straightforward. Okay. My example page is the name of the component that we are going to display. So how do I now add that to the navigation items? So again, if we go to the root of our project, we have something called console extensions. All right. And so these are all standardized things. So all you have to do is copy paste these things and then add whatever items you want. So this one says we are going to add a navigation item called plugin example to the admin perspective here. And it's going to take us to the slash example route. And the slash example route takes us to the example page component that we defined earlier. So very straightforward. You create your React component and you define your navigation items in the open shift console. Very easy to do. And now if you want to, so this is something that you can, so what I liked also is that they created something very easy for a developer to get started. So if you wanted to basically have the code running in your IDE make changes, all you have to do is yarn run. I mean, install the components and start the server locally. But you can also run a local console that talks to the remote open shift cluster, but whatever changes you make to your code are live in your own development environment. So it makes it very easy to iterate. And so actually, let me try and load one of those examples and show you basically how you can quickly iterate and have that developer experience for your plugin. Does it make sense for us or? I think it's great. Yeah, all right. Let's do that. You know, always let's go for crazy demo and see whatever works or fails. So I see now that I have my IDE here. So basically, VS code. We have, let's say our design patterns here. And if I go to my, so this is the one that is loaded on a remote cluster. Okay, you see that it's the red hat flavor of it. But now I have also an instance running locally for my development console using OKD, which is the upstream version of it, because that's how you do the development. You are going to use the like an upstream component. And I see my plugins here. But let's just do a quick change here. So for example, OpenShift design patterns here, I'm just going to change this header here and reload the UI. Okay, so let's say the level of our, because I like to call it. Now let's go back and if it worked, I see that I have my live reload in here. So as a developer, it's very easy to iterate locally. Also, although I'm connected to a remote cluster, like if I, this is a fully working console that runs locally, but that connects to a remote cluster to get the data from there. So I can test my plugin. I can iterate over my development, et cetera. And once I'm satisfied with my plugin, it's now time to build it and ship it to the cluster. Does it make sense? So first you are going to do your plugin development locally using this plugin starter that we provide. It's very easy to kickstart. And so what this does is, as you can see here, you have the run start console. It's running a local console as a container on your development workstation. And once you are done with it, it's time to push the plugin to the remote open shift cluster. And that's how it works. So basically you have to build a container image out of your repo. So there's a sample Docker file in the repo. So all you have to do is something like podman build. And it's going to build your container image, then push it to a remote repository. So for instance, quay.io. And then you have a template here that allows you to deploy your container that contains your plugin code to open shift itself, to a specific namespace that you are going to provide here. So once you do that, all you have to do is patch the console operator here by saying I want to load my specific plugin called my plugin here. And once you do that, you are going to have a pop-up on the open shift console that says there's a new plugin that has been activated. Do you want to refresh the console? And then it's going to appear on the open shift console on the cluster. So very straightforward. And just to show you what allows us to have that in the remote cluster is basically I have a namespace called console plugin template here to which I have deployed the container image that has my basically my code in it. And this is dynamically loaded by the open shift console. So I have my plugin here. And the open shift console is pointing to that container to dynamically load the content from it. So very straightforward, very well architected. So very, very good job guys in terms of engineering because this doesn't go within the console code. As I said, Serena, one of the key questions was how do I have separate life cycles? So we have the console life cycle, but if you guys want to iterate and create a new plugin every day, we don't want to constrain you by our own build cadence. So that's amazing because now you can load your plugins and iterate as many times as you want. And it can also open up the doors to some crazy ideas like a maybe a plugin marketplace or something like that. Where our partners can ship their own plugins in there and then you can decide to load those plugins. Yeah, that's some really innovative ideas. I mean, I know, like you've done one here. I know we've got Mario Loreto is trying to do one, I think for for coderate workspaces. There's a couple of internal folks who are really trying to work on and push some of these dynamic plugin pieces. So I think that's great being able to showcase that for sure. The other thing that is kind of interesting to think about is previously, when we had those static plugins, I think that was for us was one of the biggest hurdles was like you just mentioned, not being able to have the same release cadence, right? So one of the things we're thinking about internally is could we even have like the developer perspective or the admin perspective be its own plugin so that we can release the console quicker. Yeah. And that's like a conversation that we're having internally, but it's again, it's like, how do we get some of the, you know, how are we able to iterate more quickly on the console itself, not necessarily new features that we need from inside from Kubernetes or from other areas, but just really just the user experience, which is kind of an exciting topic as well. Yeah. I mean, while I was creating the plugins, I actually referred back to the Dev Console plugins plugin itself. Yeah. I think it's done and just to get familiar with it. So yeah, I think it's really awesome to have applied that also to the console itself. Yeah. Yeah, we should give a shout out to, I did not mention, Kubevert slash CNV, right? Their team was also, and that team, the developers, the developer perspective and admin perspective team that's really worked hard, I think, on getting these perspectives. I mean, the plugin implemented. So they've done a great job at doing that. And I'm just going to mention again, if people have additional use cases for extensions that they're interested in, please feel free to reach out by either creating an RFD or connecting with myself. So do we, do we expect that as we have new adopters of OpenShift that this is going to be part of what we encourage them to do, to really sort of think outside of just what OpenShift itself is and really in a larger sense about how their development teams are working and the kinds of resources and assets and other kinds of tooling that they might want to integrate. Is that going to be part of our story to new adopters? Yeah, I mean, definitely yes. And I've been a PM here. I used to be UX-ing for the dev experience stuff. I've been a PM here now for a couple of years. And that's something I'm consistently hearing is people asking current customers asking, how do we do this? So we were pushing the CRDs in the beginning. Now I think this dynamic plugin mechanism is a great one. And, you know, we hear of other competitive features or products that are solving some of the similar use cases. And I think, you know, that's also an interesting topic because we want to get into that. Well, just let me follow up with another question too. So this is a 4.10 feature, right? So within 4.10, just for clarity's sake, this is, is this a tech preview feature or is it a fully supported feature? We are saying it's tech preview because we're not, we're, we know that there's other extensions that are going to be looked for. So, I don't want to say it's not fully supported. It's not GA. The reason is that it's tech preview, though. Okay. Yeah, let's rephrase that. How do you want to rephrase that? That level, that larger level of use cases that external people might want. Right, right. And so what do you see is sort of the roadmap ahead with dynamic plugins and sort of how, how do you think they'll be evolving in the near and maybe midterm? Honestly, it's just, again, satisfying all of the internal use cases that we have from our current operators that we have at Red Hat, as well as working with customers to find out what's missing. That's great. And then, and then just solidifying, right? Making sure that everything's, I mean, we already do know that's tested, but like continuing to test out the test things and validate. Yeah. And so I've been, I've been on the field for, for many years as an OpenShift solution architect. And really that was a topic that came many times where we even had a, a group of customers in France who wanted to get together to build their own like, oh, this is what we want to do with OpenShift. And we want to be able to see this and that and this and that. And so now basically they can say, okay, let's get together and let's create a plugin that solves those issues and publish it. And then they can all benefit from that. So. Right. Yeah. I think like one area I'll give an example. I think one of the areas that we might want to do additional extensions are the, is it to quality view? Right. We have some, we have some levels there, but it's really going to be interesting to see do customers actually, or I see, you know, partners, is that an area that they do want to customize, or do we have enough there? We already have, I'm pretty sure the ability to do on like the project dashboard or the cluster overview dashboard, I think we have the ability to add a card already, right? So, you know, it's just finding out what are those additional use cases that we're not currently satisfying, that we can just continue to make that more feature rich. Sure. And so something that I haven't shown, but that is actually implemented is, is not only you can create your own pages for your plugins, et cetera, but you can also augment what's already in the console with the new navigation items. So for instance, let me see if I have an example somewhere here. I think I did something like that for image streams. But basically, you can add your own tabs. Yeah. Let me, again, let me share my screen just very quickly and to show you what this looks like. So can you see my screen now? Yes. All right. So remember the, the, the ACS security that we saw here, right? So this is like a main page in, in the plugins section. But what if you wanted, for instance, to add some extensions to a very specific item? So for example, we're going to take image streams here. And basically, you can add your own content in here. So these tabs are the ones that come out of the box with, with OpenShift. But now say, okay, we have the scan results from our external tool. What if we added a tab that shows basically the scan results to the same item, but not in a separate page, but in a separate tab for a specific item here. So it's really, I mean, there's, there's a lot of extension points where we can, you know, be creative and, and add stuff as we see fit. So again, I have added here this Argo CD tabs that show, you know, data coming from Argo CD, but adds that to the deployments sections. So yeah, I really like the, the, all of the extension points that you guys thought of. And it's not just like a very basic thing. You can do sophisticated combinations also. One of the more complicated ones I think that we've heard in the past is how do we, how does a customer provide a mechanism to hide our create project, but then provide a create project or a request mechanism so that they can fill in information like what's their cost center, et cetera, what's the information about them, what's their project. And then the project actually gets created with that metadata. Understanding more of those use cases would be really helpful for us for this, for that extension point. Cause at this point, that's one that we're missing. Yeah. So, so people have been doing that in external tools like ticketing systems. So they, they open up a ticketing system and they say, okay, blah, blah, blah. This is my project. This is the deadline. This is the quota that I need, et cetera. And then you have to create complex API or integrations between that external tool and OpenShift to be able to trigger the creation of those like namespaces or applications, et cetera. But yeah, you can do that and have an integrated experience where basically just go to that specific form and then the request namespace. And internally it's easier to develop because as I said, we have the SDK that says, okay, so you want to create a namespace. There's a function called create namespace already, you know, just, or you want to create a pod. Okay. We have something that says create pods and you don't have to write like 20 lines of code to be able to create the namespace. You just give it the metadata that you get from the form and it gets created. So it's really easier to tailor the, the, the UI and the user experience and to actually code that within the plugin itself. Yeah. I mean, this whole, this whole topic is really interesting because we do work with a number of customers who might even have, I mean, I know a couple of them actually have their own user experience department who are talking about how do they customize the console so that it fits for their use cases, right? So I think this is the, the dynamic plugins is really a game changer for those people, you know, it should make the process, we're hoping that makes that process much quicker and easier for the developer. And also for any designers who are helping them, they've already got the pattern fly components and all that. And they've got a lot of guidelines already instilled in just this mechanism, the dynamic plugin mechanism itself. Sure. Yep. So I was really excited about this feature and it delivered its promise. That's great. Yeah. And I know we're doing a set of blogs around dynamic plugins, right? So Ali and I think we might have the link there available for you, but we had an initial blog come out. But I think what we're trying to do is get some in-house people to create some demos and with different plugins and then really blog about those and show how those can be utilized. Yeah, sure. And so actually I'm going to be blogging about this feature too. Yeah. So basically, you know, a sort of getting started with the plugins and having a user guide from a customer perspective. How should I create things? What are some of the tips that we can provide them to get started, et cetera? So you had mentioned, Serena, that you wanted to get input from users and from, you know, from customers about their particular use cases and things they'd be interested in. What's the best way for them to provide that sort of input or RFE? So the official one would be to create a JIRA against OpenShift's OCP, which is of type RFE. Alternatively, you could send myself an email, which is serena at redhat.com. I don't remember Ali's off hand, so I'm not going to give his. But I think either one of those mechanisms is great. Inside some of the blogs as well, we do have links with CTAs to be able to do some of that stuff. But I would say let the RFE process or contacting me directly, because either way we'll end up connecting is the best way to get that on our backlog. Great. Well, so anything else we wanted to cover here on the subject of dynamic plugins, which is actually kind of blowing my mind. I mean, the possibilities that it opens up are really pretty amazing. Any further thoughts? Jafar. I've never known you not to have further thoughts. What I'd love to see again, as I mentioned, is to have this ability to have an ecosystem of partners created around this. So we know that there's some traction around similar projects in the CNCF. So with this notion of a plug-in hub or stuff like that. And what I want actually is, what I'd like, I mean, is to have a marketplace of plugins to which anyone can participate. And then as an OpenShift user, you can just go ahead and say, okay, I like this plugin, install it, and it deploys whatever it needs in the background. Like, so, of course, you need to be an admin to do that, but it can create the containers, create the namespaces, activate the plugin, and you can get started very quickly. I think that would be really interesting to look into. I don't know if you guys remember, but back in, I think it was October or December of 2020, we used to have an OpenShift developer experience on show on OpenShift TV. And what Ali and I did was a console customization competition. And we ended up having a Git repo where a bunch of people put in their sample customizations. But this is a step further where it's really building a community around that. So that's something we should definitely look into. Actually, the competition sounds like a good thing to revisit. Yep. So I have some ideas I can share with you, Serena, after all. So one additional question from me. So, you know, we've talked a lot about sort of the customer use cases and interests there, but we've also alluded to partners and so on. And in particular, I guess I'm curious about sort of interest from the ISVs because I start thinking about sort of the potential for some of them to be interested in this. Is that something we're looking at and seeing interest in? There's definitely some interest for sure. And I think some of our current operators, if they wanted to take that extra step, the experience could be even, you know, obviously more integrated, more seamless by extending the UI with some of their capabilities. Yeah. I think the, you know, the sky's kind of a limit with dynamic plugins, especially for these people who are already creating operators. All right. Yeah. But again, you don't need an operator to be able to have the plugin. I mean, you can deploy very easily because creating an operator is a task. Agree. I mean, you have to get familiar with all of the things that needs to be done around the content itself, although we do provide like the operator SDKs and stuff like that. But if the goal is just to create a simple plugin that does things outside, just remember that they can do that. And remember, guys, that you can do that without the operator. Okay. Well, it doesn't require an operator, but it's intriguing to think about if you are creating operators, how do you use the dynamic plugin? Oh, yeah. Right. That's the thing when you were saying ISV and partners, right? Right. And that's the thing. Operators that are already available through the marketplace or through operator hub. And if they wanted to take advantage of this dynamic plugin, and I have a couple ideas of my mind, but I'm not going to say them because I haven't specifically spoken to those companies, but I think we could do some very cool things. Agree. Well, and I think part of it is also not to be overwhelmed with the possibilities this early on in this particular endeavor, because it looks so inviting. The possibilities in terms of the developer experience, the possibilities in terms of how to extend the functionality of operators, the possibilities for ISVs and sort of their customer experience of their product running on OpenShift. I mean, the mind races about how many different kinds of things this could potentially touch. I have one more question for you, Jafar. Have you tried doing anything around like RBAC pieces? So you know what I mean? So maybe you're going to create, because the dynamic plugin mechanism from what I understand, we can do something just for the cluster admin, but we could also expose things for everybody, right? Yeah. So my understanding is that in the back office, it uses the OpenShift RBAC mechanism. So if you're not allowed to create pods, so you won't be able to create pods either, although if you have something exposed there, I haven't played with RBAC, but that's definitely one of the things that I'll be looking at, because I mean, it's an important topic to be able to maybe, you know, not show things when they are not allowed to do that. Right. So you talked about like this new perspective, right? Like what if you had a new perspective for certain roles, right? That as a developer, I wouldn't see. Yeah, sure. Right? Like today, what we do is the developer perspective and admin perspective are always there, but we hide some of those nav items. The possibility could be, could you create a perspective that's only shown if you have specific rates? Yeah. Yeah. And I would, I mean, that's definitely something to look at. And I would even push it a bit further when you said that we have some customers who work with their design teams to make OpenShift fully integrated into their own like portals. So how crazy would it be to like totally hide the developer and admin perspectives and just have like the one custom perspective that they want? Does it make sense also at some point or for, I mean, for a specific type of users? Is it something? And that's a great question. And those are some of those requirements we want to understand. Yeah, because then they just, they can just go to that page directly and they don't have that admin or developer. They have my company, Acme company, and that's all they see. Yeah. And we've also done, lately, I want to say in 4.8, we introduced user preferences, for example, where we say, what's your default perspective? Those are some of those, like we need to, those are some of the areas that we haven't thought through. If you add another perspective, is it then available in user preferences? And you know what, maybe the dynamic plugin team has thought through it and I just haven't talked to about it. Like some of those areas are areas where you need to dig in a little bit deeper. Yeah. So definitely the RBAC thing is taken care of because when you run the console, you have, I mean, you can run it using the authentication and then whatever you see is only the things that you are allowed to see with your user. Right. In terms of resources, but like showing perspectives or not, depending on a role, this isn't something that I have looked at. But yeah, somebody's asking about hopefully this can't be abused to show things they couldn't, shouldn't be able to see either. Yeah, no, definitely not because again, it's using the RBAC, the OpenShift RBAC natively. So it's definitely no, they won't be able to see things that they're not allowed to. Because it's using the credentials that you are logged in with to make the queries. I think the difference could possibly be could you go to a page and it will be empty because you don't have access versus that nav item being hidden. Yeah. That could be the differentiation that might be the experience that's different. Yeah, well, we already have something like that. So for example, when you are logged in as a nonadmin and you go to the operator hub page and you don't have, so it says restricted access. But it's not like a blank page. We have some message, clear messaging that says you are not an admin. So there are already some mechanisms in the console to do that. But yeah, we need to see how easy it is to be done with a custom plugin. If you see a blank page, you're supposed to see a blank page. Yeah, exactly. All right. So thank you very much, Serena. It was really a pleasure having you here and thanks to you guys and the engineering teams to provide this awesome feature because I'm sure all of our OpenShift customers will be delighted to play with it. Yeah, thanks for having me. And I know Ali wishes he was here, but he's in the West Coast. So it was a little early for him. And shout out to him as well as like Sam Panjit and a number of the engineers on the UI Dev side. They've done a great job with this work. Thanks for having me. This is really remarkable stuff. And thank you again for joining us today. This has been incredibly informative. And so I think that brings us to the end of this episode of the Level Up Hour. Again, everybody remember to like, subscribe, and share so that people know we're here will be back in two weeks. And so perhaps we'll be joined by Scott, who's follow just showed up and mine and Jafar and everybody else. But anyway, thank you for joining us today. Thanks again, Serena. Thank you, Jafar. I'm Randy Russell. And have a great day wherever you are. Thank you very much. Bye-bye. Bye-bye.