 Good morning, good afternoon, good evening, and welcome to another episode of Working on OpenShift. This is so awesome. We are an open culture that is really, really decent. Everybody has something that they think it's good. On top of the red hat portfolio. Hello and good morning, good afternoon, good evening wherever you may be, and welcome to this week's Ask an OpenShift admin livestream. So, thank you very much to everybody who is joining me today. Hopefully you're all able to hear me well. I hope everybody is safe out there. And today is exciting for a number of different reasons. So, first, this is the first stream we've had in two weeks. That always makes it a good day. But second, you'll notice that I was only by myself for really one stream. I've got two guests with me today to talk about our topic. If you're paying attention to our titles here, that's going to be console features, console customization, something that I know a lot of folks are interested in. But you'll also notice a third face there. And that is Johnny Rickard. And Johnny is a friend of mine. We've known each other for, gosh, over a decade now. Probably even well over a decade at this point. We used to work together long before we both came over to the vendor side. And very serendipitously, he has been able and agreed to join as co-host of the Ask an OpenShift admin live stream. So, Johnny, if you don't mind, tell the folks who you are. Awesome. Thanks, Andrew. Yep. So I'm Johnny Rickard. I've been in the IT industry for over 22 years. I've pretty much been a Linux and Unix nerd since the beginning. I've been at Red Hat for the last five and a half years working in consulting. I was a senior architect. I just recently transitioned over to engineering as a special projects engineer. So got a lot of history with CIS admin and system engineering and now hopefully going to get to dive into more of the day to beyond operations at OpenShift. Man, saying 22 years makes me feel old because you and I aren't that different in age. So I was over here doing the math. I was like, carry the two. Oh, man, this is bad. Well, I'm really happy to have you join. And I know when we were talking about this beforehand, I was saying how you've been in consulting for the last, I think you said, five years or something like that. So you have been in the trenches, hands-on, implementing, working with folks who are doing OpenShifts day to day. So it's not just the presales where we come in and tell you all the fancy things that it can do. Rather, it's the, no, we're going to make it do all these things. Yeah, absolutely. And, you know, like a big thing that we talk about when we're going into consulting is like the presale stuff is all about like the art of the possible and we're really there for the art of production, right? Like we're trying to get you into production so that way you can run your workloads and everything on your clusters. Yeah. Yeah. So I am super excited to have you join. I know you bring a wealth of knowledge around not just OpenShift and Linux, but around, you know, a lot of things related to running production systems, you know, for a long times or for a long time. You and I were, we were effectively peers in a previous life, right? A couple of jobs ago. We just were at different sites within the same organization. And it was a lot of fun. I always liked coming out to Texas and getting to visit and, you know, eating lots of barbecue because that's what you do in Texas. That's what you do, right? Yeah, yeah. So as of here in North Carolina, on the other hand, it suddenly within the last 36 hours turned very cold. Our heat turned on for the first time. So it's a rough, it's a rough life we lead. Yeah. Texas, I think it may rain today and it's in like the 70s right now. So like, we'll see how it goes. It might, it might warm up to 85. We'll see. Yeah. Well, knock on wood. We know how it is when it gets cold in Texas. So that's true. That was a low blow. Oh, that's good. All right. So I won't dilly dally or delay any longer. I will, I am happy to introduce our two guests who were, we're very, very happy to have on. So Ali Moobrum, Sam Padgett. So Ali, if you don't mind introducing yourself. Sure. Thank you for having us today. So names Ali Moobrum. I am the product manager for the OpenShift console. I've been with Red Hat for the last three years. And I'm very, very excited to be here today because we're going to show you some really, really cool stuff that we've had in the works. And in order to do that, I brought our lead architect, Sam Padgett with us. So Sam, you want to introduce yourself? Hey, my name is Sam Padgett. I've worked at Red Hat for six years, all in OpenShift, all working on OpenShift console. So I was originally a developer while we were working on OpenShift version three just before we shipped 3.0. And I've been team lead and now UI architect working on OpenShift. So excited to show all the things we've been doing. Well, it's hard to get more experience than that, Sam. Basically, since the modern OpenShift console has been impressed. Yeah, pretty much. Yeah, we were a team of just a few people, like three or four people at the time that we've grown. And now we've got like dozens of different people contributing to the console today. So yeah, it's been quite a journey. Yeah, the whole OpenShift team has kind of exploded, which I'll talk more about that in just a few moments. I did want to go back. You know, Ali, you pointed out that there's a lot of new stuff happening. I've been wanting to do this stream for like a year. And it's been one of those like, you know, yeah, but just, just wait, like, yeah, there's a lot of, we're working on some really cool stuff. Just wait because the historical set of things that were capable or possible. While good, there's so many exciting things that are getting ready to happen. So I'm very happy that we are finally able to have the stream and to talk about these things. So before we get to that, I just want to spend a couple minutes doing our top of mind topics for this particular week. So for anybody who is new to the stream, or if you've forgotten in the last couple of weeks, I know it's been a little bit since we had, or it's been a little sporadic recently. But this is one of our office hours series of streams here on Red Hat Live Streaming. What that means is that we are here for you, for our audience. So any questions that you have, any things that are top of your mind, anything you'd like to talk about, please put that into chat. So whatever platform you're watching us on, whether it's YouTube or Twitch or whether you're on your phone or whether you're at your desk, put it into chat. So we use fancy software here called Restream. It'll make sure it goes across all of those. And our producer in the background, our silent advocate here, Stephanie, she makes sure that we see all of those, that we address as many of those as possible. So thank you, Stephanie, for working diligently in the background to keep us on track and in mind. So the Ask an OpenShift admin stream, we like to, or I, you know, I guess because I'm the only one who's been here for more than one stream, right? So I like to focus on a couple of things up front and that is what I call the top of mind topics. These are effectively things that have happened that I feel like you, our administrator audience, should be aware of or should be, might be important to you. It's not everything in the whole world, right? I actually had a chat with somebody about creating a newsletter for such things, but hopefully it's some things that help you do your job better. So the first thing that I want to talk about is, to what Sam was saying a moment ago, OpenShift as a team has gotten massive and you would expect this as OpenShift has continued to grow in popularity. You know, Ali over on the PM team, when I joined three years ago, I think I was the third tech marketing person and there was roughly 20 PMs at the time and now we're up to, it's close to 60 PMs. You know, the tech marketing team is now close to 20. You know, it's just grown in leaps and bounds and the reason why I bring that up is because, well, it's continuing to do so. So there is a number of positions that are opening on the product management team. So I saw Kirsten Newcomber posted, I think it was four security centric product management roles the other day. There is I think five or six tech marketing positions that are open on my team. So if you go to, you know, the red hat careers page, you search for that product management for that tech marketing, any of those things, please. If you have any interest in joining us and working on OpenShift and doing all the great things that we do, we'd love to see your application come in and hopefully someday we can work together. So I'll move on from that to recap a couple of things or to revisit a couple of things from the last stream. So first we had, I just announced or had just talked about how the updates from 4.7 to 4.8 are blocked. So let me share my screen real quick. All right. So I shared this security advisory. So this is actually an errata bug fix advisory. So I shared this last time basically saying that's the update edge. If I could find the right word here from 4.7 to 4.8 was blocked. So the fix is in OpenShift 4.8.16 and later and 4.7.25, 26, whatever it was. However, that release was not promoted from candidate into fast or stable. So what that ultimately means is that well updates from 4.7 to 4.8 are still blocked. So you can use the fast channel. I believe that there is a fast channel. Let's see, am I logged in here? I am not. So I will have to log in while we're off screen. But anyways, if you were to look inside of the channels essentially 4.8.15 is the current stable release. I think it's 4.8.17 is in fast and candidates if I remember correctly. So it hasn't been promoted to stable. So if you're using stable channel, move over to fast. If you think that that bug doesn't affect you and if we click on the bug here, this should take us to... So if you're not using hosted egress IPs, you know, just go through, evaluate this, determine whether or not it's something that affects you, whether or not you're wanting to accept the risk associated with that. But essentially right now it looks like this is the only blocking bug and the reason why they had removed that update edge. So if you want 4.8. later or if you want to do that 4.7 to 4.8 upgrades, definitely check out that and make a determination for yourself and your organization. So the next thing that I wanted to talk about is regarding the... One of the things that we talked about last week with the... Or excuse me, two weeks ago with the what's new in OpenShift 4.9. So a couple of things came up with that. So the first one was I talked about and we showed deploying single node OpenShift utilizing... There we go. So we talked about deploying single node OpenShift. I used the CLI to do that. I actually showed it in a virtual machine and one of our PMs reached out to me to point out that even though it technically works in a virtual machine, it's really only fully supported right now with physical servers. So just please be aware of that. If you want to test it, if you want to work with it inside of virtual machines, VMware, Rev, et cetera, should work. Just keep in mind that it is only fully supported with physical servers. So if you want to use that in production, be sure to use physical. The other thing that we talked about last week or two weeks ago rather, I'm going to keep saying that until I get it right, was the change to the EOS policy that starts with OpenShift 4.8. So if I can find that blog post here... Oops, and I lost my window. Let's see, let's share our window again. And this time we're going to go to cloud.redhat.com slash blog. And somewhere inside of here is our... Normally I have a link to these things. So this time is on your side article. So in this blog post, Mike Barrett talks about how as of OpenShift 4.8, essentially all of our releases will be supported for the same period of time. If we scroll down to this graphic, this graphic shows basically 18 months for each release going forward. So one thing about this, I definitely want to highlight that this dates are estimated. This is not a roadmap. This is not a promise of specific versions at specific times or anything like that. This is just for illustrative purposes of that 18 month timeline. So I just definitely want to eliminate any confusion there. But the difference between an EOS and a non EOS release going forward is effectively the update process associated with it. So if all releases are supported for 18 months, the difference between EOS and non EOS is that from, for example, 4.8 to 4.10, you'll be able to do an accelerated update where effectively it pauses the compute nodes, updates the control plane sequentially, so 4.8 to 4.9 to 4.10, and then unpauses the compute nodes so that they go directly from 4.8 to 4.10. So unfortunately, that does not apply with 4.6 and 4.6 US. So 4.6 non EOS is currently out of support with the release of 4.9, but 4.6 US, in order to get to 4.8, you do need to do a sequential update. So just follow the normal update procedure, so 4.6 to 4.7 to 4.8, and then in the future when 4.10 ships, you would then have that accelerated update process available. So a bit of disappointing news, I think I mentioned that last week that I would find out the answer to that because a couple of folks have been asking, so yeah, I wish that we could do it before that, but it turns out there's a lot of technology in the background that they're using. They actually back ported some of that from what I understand from 4.10 all the way to 4.8 to make all of that happen. I'm in RHE interviewing for a container infrastructure consultant position. Any tips? So congratulations. Getting past all of the HR stuff these days alone is a pretty impressive feat in getting to that point. So, Johnny, I've not worked for Red Hat Consulting, so I don't know if you have any thoughts on that? Yep, and I know it's going to sound kind of cliche, but honestly just go in and be honest about your experience and be ready to explain how you've got to explain your initiative, how you approach learning, how you approach troubleshooting, kind of taking into consideration some of the things that you've done as far as designing or when you're talking to a customer about implementing a solution that you maybe need a whiteboard and kind of go and get permission from them on something like that. So those are probably the key areas to focus on. It's awesome that you have your RHE that's definitely a good, it's a big bump for me if I were to be interviewing you, I'd take that into massive consideration. So congratulations on that, like Andrew said, but yeah, just be honest about your experience. Know what you don't know and don't be afraid to say that you don't know something because there's no expectation that you're going to know everything. So just go in and have fun with it. Yeah, it's funny you say that when I used to interview folks back when I was a customer, back when Johnny and I worked together, I would interview the Linux and Unix admins and my approach is always I'm going to ask you like the most esoteric, crazy, unknown things possible, not because I want to test your knowledge of, you know, Unix or Linux, but because I want to know that you understand how to find the answer. Like, oh, well, I'd start by looking at the man page for this or oh, I would go and search for this inside of the help files or whatever it happens to be. There's just too much when it comes to, you know, whether it's Linux, whether it's OpenShift, whether it's Kubernetes for anybody to know everything. I also, when I started working for a vendor, it was funny because so I work for a storage vendor and I was a virtualization expert and it's one of those well, I can teach you the storage but I, because that's what we do, like we're a storage company. So we can teach you our own product, but I can't teach you the other, you know, our partner's product. So still 4.6, still a few months until 4.6 goes into life. Yes, I think there is a brief overlap period there, but yeah, 4.6 non-EUS, it is, the end is nigh, if you will. So that's really all I've got for today. So I don't have any other top of mind topics, anything that we really need to address. So hello, Khalid. Thank you for joining us again this week. So with that, let's talk about the console and customizing the OpenShift console. And it's funny that we talk about this week. So over in the Kubernetes Slack channel, somebody asked me, like Monday, like, oh yeah, how do you, you know, two weeks ago we had talked about how can I identify which cluster I'm looking at, which cluster I'm using, you know, quickly and easily. And, you know, I suggested just a console banner, something very simple, very easy. And somebody asked me about that in Slack the other day. And it was, oh yeah, very good timing, excellent. Jamie, yeah, you might have been the one to ask or I know you were definitely in that thread over in Slack. So yeah, Ali, Sam, console customization. Yeah, let's do it. Sam, do you mind bringing up the presentation real quick? So the OpenShift console, like Sam's bringing this up, we've kind of designed this thing to be extensible from day one, right? And we had to do this not only for our customers, but we had to do it for our internal teams. So the way I look at OCD console is kind of a layered UI, right? And by layered UI, I kind of mean we have like serverless team, we have pipelines team, we have the CNV team. As our customers pick and choose what technologies and what features and capabilities they need, the UI will kind of grow with it, right? So it'll allow all these third party or not third party, but all these extensions to come in and to really expand the UI and give our customers a great experience. So if you go to the next slide, I'm going to talk about just high-level like why we kind of did this, right? So number one is we really wanted to empower our customers to build like a Kubernetes platform that's right for them. And that's a little bit I talked about of how with bringing different features and capabilities on, you could expand your platform or you could just have a smaller platform. It all depends on your needs, right? So we want to enable our customers to come and do that. So when we built the OpenShift platform, we, A, wanted to be able to customize that, but we also want to give the ability for our partners and our customers to customize and extend the platform themselves. So if you go to the next slide, I will start talking about the different mechanisms we have to extend the platform. So just to extend the functionality, we have our operators and our operator pattern, where you come in and you install an operator, for example, CNB. And if you enable CNB operator on your platform, you now can run and manage VMs right within OpenShift. And with that, you could also get UI that comes into the console and you could natively from the OCP console come in and manage and run your VMs, which is fantastic. But that's for our own internal CNB or OpenShift virtualization add-on, right? Not only we want to allow that to happen, we want to partner to come in. So for example, let's say a MongoDB or a CrunchyDB or whoever wants to come in, we have the ability for them to come in and extend the platform as well, which is great. So if you look at the items that are listed here, we have console config, which is just for coming in and updating the branding to allow our users to come in and customize that. The next thing we have is console CRDs, which is we came in and provided very specific accessibility points to allow users to come in like put the notification banner and so forth in there. And then the reason we did this in OpenShift 3, users were able to come in and kind of just inject their own JavaScript and their own CSS, which was really flexible and powerful. But the problem was every time they upgraded, that would break, right? So with this mechanism, when you upgrade, we actually are able to come in and ensure the things that you've added work and work properly. So that's fantastic. And I'll do a quick overview on those two items. And then the third item is the OLM descriptors. And this is when you install an operator, if you add OLM descriptors for the objects that that operator manages, we automatically give you UI based off those OLM descriptors. And they're pretty powerful mechanisms. So we not only allow the OLM descriptors to come into, like, add and improve the creation and update experiences of CRDs that are managed by that operator, but we also allow OpenAPI v3 schema to auto-generate the creation form from the beginning as well. So you automatically get the form with the schema, and then you add the OLM descriptors and you'll get a higher level, nicer interface for that. And then today, the big thing that we're going to talk about is the new console dynamic plugins. And we'll do a deep dive here. Sam's going to come in and do a demo and talk through kind of how this has been implemented and how users can come in and create their own dynamic plugin. This is really to come in and build a solution on top of the OCP console. So this is, yeah, good? Ali, I'm just going to interrupt you briefly because I want to kind of review those things that you talked about so far just very quickly. And Sam, I don't know if you're intending to show those or not. I don't want to step on your toes. I do have a cluster where I can walk through those a little bit. Yeah. Primarily we're going to look at the dynamic plugins in the demo today. Okay. So let me take two minutes and I'll just run through what that looks like real quick. Okay. Awesome. All right. So what we're looking at here is this is my normal before the stream. Andrew always provisions a cluster that we can have available. So this one is running 4.9.0. You can see I need to update my open shift install command. So a couple of the things that Ali was talking about there is for example, and please correct me if I'm wrong. If we go to, you know, our installed operators here, you know, those LM descriptors, effectively it's this set of information here where you can look at and see what are the CRDs that are managed by this? What are the ones that need to be associated with it? This is the package manifest. Let's go with the terminal, the web terminal. So if we install this guy. So one, I know that this is all some fancy integration in the background, the open shift virtualization one. I was looking at the new one with 4.9. And so they've integrated like a whole slew of questions and config and all kinds of other stuff into this GUI. It's really quite impressive. But yeah, so essentially what we're looking at here is, you know, the GUI based integrations for, and it's not done installing it, for managing those CRDs associated with the, or the instances of those CRDs, excuse me, associated with the operator. So why are we waiting for this one? Do you want to go and show them how to create like a notification banner and some of the... Yeah. All right. So I happen to have that up in the documentation here. So let me copy this page out and I'll post this into the path there so everybody can take a look at it. So what I've got here is just a link to the documentation for the customizing the web console page. So a couple of interesting things here. So first with 4.9, we talked about this before, you can customize the routes. So if you don't want to use, you know, this console dash open shift dash console, blah, blah, blah route, you can change that now. But the one we care about at this particular moment is down here. Like this creating custom notification banners. So I'm going to literally copy this out of the documentation. I'll go up here. We'll go to here. So I can create something. I'm not creating a pod. I'm just taking a shortcut over into this GUI to access the ML. And can I show you another? Yeah, please do. If you click that plus at the very top in the method. This one. Oh yeah. Right there. You don't even have to hijack the pod. This is what happened when you have the GUI guy. I learned something new. Yeah. So one other method that I like is if you, on the scroll down to the administrator section and go to CRDs, custom resource definition. There you go. And then search for console. You're going to see all the console type CRD. So go to console notification. Go to instances. Click create console. That is phenomenal. Right. And then on the right, we actually have the schema. Yeah. Descriptions and definitions next to you. And we've already inputted a sample. Sample item in there. Oh, that's great. And you can, you know, you saw, I just clicked this, the schema, the console notification specification. Right. So this is basically the same thing is walking through and doing like an OC explain. Exactly. Everything that you want to know. So let's do, we'll do a red hat color here. And then we'll just click create. And what we should see almost immediately is our banner pop up with a link at the end of it. It's going to be easy and I can create another one. So console notifications create. This one, we want to be better bottom. Yeah. Let's make this one purple. Yeah. Cause you can use, it's just HTML. So you can use HTML colors in here too. Yep. That's right. No, no. And one down below. That is awesome. So yeah, it was, I was having fun with this the other day. We continue this game and some more. Yeah. Again, I want to make sure that you all have, and we can't go over today. So I want to make sure that you all have plenty of time to show the dynamic plugins. So let's, okay, let's just show maybe one more. Okay. One of my favorites. So if you go back to the customer resource definition section, type in console again. And so one of my other favorite ones is, and we have a bunch here. So you got like the CLI download, which allows you to put your own downloads. We're not going to do that one, but you could show where it shows up. Yeah. It would be under command line tools. Yeah. So if you, if you had your own download, you could put that there. So one of the use cases that we have is, for example, let's say someone installs a serverless operator. That's based off Knative. Knative has its own command line. That operator now actually installs a link to the Knative CLI right there, then in there. So that's really cool. There's console quick start. So if you want to make your own quick start, you could do that, which is really cool as well. If you want to highlight that, just click the help menu icon at the very top. She'll list out quick starts as the first item there. And here's a list of all the kind of quick starts. So these are essentially interactive tutorials that will walk people through doing some kind of onboarding activity or exercise or whatever you want. It's literally just embedded markdown in a YAML. Very easy to create and extend. In fact, we can go ahead and add one right now, or we could do the other one, which is intending to show was console YAML samples. So if we go back to the customer resource definition. I could type. All right. So there we go. Click that one. And this instance is create console YAML sample. So the cool thing about console YAML sample, and this is the use case I would get a lot, is I need to go do something and I forget how to do it. So I kind of go Google it to find an example. I grab that example. I bring into the UI. I create that resource. And then I tweak it to do what I needed to do. Well, we're like, well, why do people have to keep going searching for it in the web? Why not if they've done it once and they've actually got it working the way they want it? Why don't we just allow them to save it right then and there? So the next time they come to that resource, they have that example available for them. So if you look at this default sample we have, we're actually going to extend the kind job. And we're going to build a sample called example job. So if you click create, that was created. Now if you go to work workloads and go to jobs and you click create job, you will now see next to schema samples. And we just added the sample. So if you click try it, it will replace the existing YAML sample with the example that you just added yourself. Super useful and helpful. Yeah, I could see this being a very easy way to add, like you said, those common things that you come up with. I'm already brainstorming and all the demos that I do of just having my script that goes through. So that way I don't have to copy and paste, but having a part of my cluster setup script go through and add these things in there. So that way when I'm doing a demo, I just click the button. Exactly. That's great. Thank you. No problem. Should we go back to the operator and show that last? Yeah, yeah, let's do. All right. So say I'm going to share your deck. We'll kind of jump back into the, all right, so let's go to the next slide. So we kind of glanced over this one. We're going to talk about this a minute. So we allow you to come in and customize the branding for open show. So here on the screenshots, you see I just replaced the official logo with the generic Kubernetes logo. It updates the mass head updates about page. You can also come and tweak the login page. As well as the error page and put official logos there. Next item was the next item was CRDs. The console CRDs, which is we kind of demo the notification. Next slide. Yeah. Yeah, here we go. CRDs. And this is the one we showed. You could customize links, notifications, command lines, YAML samples, quick starts to now add it in there as well. So those are all customizable, and it's just via YAML, right? Next slide. So this is what Andrew was about to show with the web terminal one. And this is OL and descriptors. So when your operator comes in and gets installed, your operator usually manages a bunch of custom resource definitions. So let's say, I'll give the example, I need to create a database instance now, right? We will automatically generate the creation form for that via open API B3 schema. But it's usually kind of rough, right? Because, like, for example, if you're one of the fields needs a secret, you're going to have to type in the secret as just a basic text field. So we have something called OL and descriptors, which will override fields. And one of the descriptors we have, for example, is like the secret type. And we put the secret type there. It actually gives you a dropdown of all the available secrets. And you can just select that. So it adds a level of niceness on top of it to just make that UI experience a little bit easier, a little bit better. Because who wants to sit there and type out a secret? I don't. Out of curiosity, is this a part of the CSV? This is part of, yes. Yes. This is all defined on the cluster service version, yes. Okay. So if you're creating your own operators or especially for our partners who are creating operators, this is a great way of making it much easier for folks to input data into that CRD definition. Yeah. I was just going to say it's nice because it's all declarative, right? So you don't have to write any code to do this, right? You just define it once in the CSV and then the console itself will take care of rendering all these specialized widgets. So it's a nice, simple way of, you know, having a richer experience. And with all the descriptors, you could do some really cool things like showing required fields, hiding different fields that, unless like, for example, you might select, oh, I need to select a node. And if you select node, then you get a bunch of options like, okay, I should input the name and whatnot. So it allows you to hide sections of the form based off of input and again, really, really improves the experience versus just getting like every field in the schema which can be really, really long and cumbersome. So we wanted to prove that experience. All right. So let's move on from that and dive in, start doing a deep dive into dynamic plugins. Let me start with this history part and then I'll hand it off to Sam. So dynamic plugins kind of came about or at least at the beginning was we had static plugins and the reason we had static plugins is I talked a little bit about that layered UI approach. Like you start with the base console, but you know what, now I want to have OpenShift virtualization or I want to have serverless capabilities or pipelines or get-offs. We wanted our other teams to be able to come in and contribute UI code and update that experience and have it be native right in the console. We didn't want someone to have to go to like some other UI to do serverless or to go manage their VMs. We wanted them to be able to do it right there natively in the console. So we started with a static plugin mechanism. It was our first iteration of creating plugins. It was only available to internal teams. There was actually, we have like a mono repo where all the teams contribute their plugins to that system. And the other issue that we kind of discovered was we could only update the plugins with every OCP release. So for example, let's say OpenShift pipelines is on a faster release cadence and they want to update their operator. They weren't able to update the UI with that operator. They had to wait to the next version of OCP console to come out to update their UI. So that was one of the issues that we encountered. So we went to go to create dynamic plugins to allow all these different operators to be able to release at their own cadence. So handing it off to Sam. Anything I missed there? Yeah, I think you hit on all the big points. This was really, you know, something I mentioned earlier, our team has grown a lot and we've got a lot more UI developers contributing to console. So this was kind of our first step to allow more teams within Red Hat to contribute, right? So it's still all through a single monorepo. It's tied to a single image with static plugins. Our long-term vision was always to try to break that out, right? So this is the first step which leads us to dynamic plugins. And dynamic plugins in a way are similar to static plugins. Like we have the same goals with them. It's really an evolution of it, right? So what we wanted to be able to do is take what we've done with static plugins in the repo and break it out. So that teams could work a little more independently. They could deliver on their own schedule outside of the normal open shift release cadence. And to be able to most often deliver it through an operator, although that's not required, they usually deliver plugins without having an operator. So again, this was an evolution. It's all based on some new features in Webpack 5 called Module Federation which allows you to basically have your own project and build your plugin and have everything dynamically linked at runtime, right? So it doesn't have to be built as part of the console image. The console will discover your plugin, load it, and you can dynamically update the UI and update your plugin without needing to update all of the open shift, right? So it's a nice evolution. This is still very early. So it's still an alpha API. We're beginning to use this internally for some of our plugins. If you look on the cluster, there is a console plugin resource that's still an alpha resource. I do want to caution that we're kind of looking a little ahead here. We want to show you what's coming and show you what will be possible. This is still under development. So I would treat this as an alpha API right now. But we wanted to give you a preview of what's on the horizon here. So what is a plugin, right? A plugin itself is really a... Well, it's a manifest that has the plugin metadata, for instance, like the name, the compatible versions, and some other information about your plugin. It is a list of extension points that your plugin wants to take advantage of. So this is all declared in a JSON file. It's all declarative, and we have all kinds of extension points. So some really common ones are I'd want to extend the nav. I want to add a new nav item into the administration perspective under this navigation group. Right in this section. You can do that. Another really common example is I want to replace one of the details pages for a resource. So my operator adds a new custom resource. I want to have a custom experience in console for that resource. So you can do that. Similarly, you can do it for list pages. Are you able to... Somebody asked me recently if they could have the term I use as iframe. I don't know if that's still the modern technology or not. But effectively, hey, I want to link out to my storage management console, or I want to link over to my DNS management console from within the OpenShift admin console. Right. We do let you have new pages to console that are just basically a blank canvas. So you can put anything in the page and potentially you could even iframe something although I think for a better experience it's nice to build it out natively. It's pretty easy if your application is a react application in particular and you use federated modules to do that. We want to make it very easy to be able to integrate with console and even if you have an existing page be able to expose those UIs directly in the console without needing to do iframes or anything like that. Yeah, this is going back to my old days. I was a viewer administrator. I worked for a storage company who did integration with the center console and this is very much what that reminds me of is having that interface where I can interact with my companion tools, my companion software hardware, whatever it happens to be with my platform. One of the many reasons I'm excited about the dynamic plugins. Yeah, it's really cool and I'll get to them in a moment so you can see it in action. The third piece is the actual federated modules. So you will have to write code to make use of dynamic plugins. If you want to make simple customizations, the CRDs and the OEM descriptors are a good fit. I just want to add a link somewhere in the UI or I want to tweak a few things on my opera in details page but for deeper customization plugins would be the way to go. You have to write code it's a React console so your plugin should use React components. We do make an SDK available and this is still under development but we have an SDK available with a bunch of utilities for making requests out to Kubernetes making API requests for watching resources and we also have a bunch of shared components that we're working to make available so that your UI is consistent with the rest of the OpenShift console if you reuse these components or things like list pages filter toolbars, details pages and those sorts of things. So again, yeah you declare all your extensions to the JSON manifest pages routes catalog items, developer catalog tabs to our dashboards there are literally dozens of places you can extend the UI and then you can plug in your own React components where you need to so we want to make it very flexible there are not a lot of restrictions on what plugins can do you can bring your own JavaScript code your own CSS and you have a lot of flexibility in terms of what you build alright so broadly this is the architecture so I'll work from the bottom up here so we have the console core here which is really the framework for running plugins today that also I would count like the existing console pages as part of the core but you know we're working to split those out so eventually we want the core just to be almost a lightweight framework for running plugins and then everything that sits on top of that runs as a plugin so like the administration perspective the developer perspective you know openshift pipelines Kubebird and container native virtualization like everything should be able to ultimately plug in as a dynamic plugin consoles go ahead I would imagine that makes it easier to update kind of the all of those other components not just feature like openshift for yeah absolutely long-term being able to update any of those components independently and potentially separately from the normal release cycle so you could go into like operator hub and control when the console itself updates having upgraded the entire cluster to get new console features that's an interesting concept it kind of reminds me of what Google's doing with Android or Microsoft has been doing with Windows or we do with REL decoupling everything from the core so that they can more easily update it absolutely so console itself uses a project called pattern fly it's an open source project that has a bunch of UI widgets and it's used throughout like the various red hat web applications provides a common look and feel as well as common components for building web applications Mast head nav form elements buttons all those sorts of things are provided through pattern fly all those pattern fly components will be available through any of the plugins so if you're writing a plugin you can make use of it and I mentioned already it's all built on React so that's what we use is our library for building plugins and the Oval Shift console itself so on top of this the next layer is the extensions the various extension points that we make available to plugins throughout the UI and again there are literally dozens of these and we have like a markdown document that's generated from the code that outlines all of them so there are lots of places you can plug in and then we have of course the SDK and shared components that you can reuse so if you're building a Wisp page you don't have to start from scratch you use the common list components you get your data you pass those to the common list components and a lot of the heavy lifting is done through those shared components the SDK and then of course on top of it are all the plugins so today it's still very early it's an alpha API we're beginning to use it internally for console itself as well as other Red Hat plugins eventually we want to make it so that when you install the various Red Hat operators that extend the UI that's all contributed through dynamic plugins from the operator pipelines container native virtualization OCS and so on eventually we want to open it up to third parties and cluster admins as well so admins can write their own plugins that extend the console and add different capabilities alright so with that I did want to show a demo so let me go ahead and switch context here so this is the I'm sure you all know it's the OpenShift console I'm actually running a 410 Nightly Sam you might need to full screen and bump up the magnification a little bit yeah I can certainly do that let me how does that look okay so I'm going to go up and click the add button that Ali showed us earlier so I can let me go find some of these plugin manifest that I have already here so I'm going to deploy one of our wait can I time out a second and acknowledge that you just did a drag and drop of the yeah I learned something new every single time yeah just drag and drop directly onto it we also support now multiple YAML documents so you can import them at once in the UI similar to what we do with the CLI so we have a demo plugin that's part of the OpenShift console repo I can show you where it is really quickly and we have some links available through the slide deck as well for some of this stuff so this is the OpenShift console github project we have a dynamic demo plugin here you know of course everything is open source so all the source code is available and we have some instructions here for how you can run and use the plugin both locally if you're doing development on the plugin as well as deploying it out to a cluster so really what I've done here is I'm doing this step here where I drag this manifest file over into the import YAML view here and I just wanted to show you what resources this is going to create there are only three here that is creating so it's creating a deployment which will run an image with an HTTP server that will serve the plugin and all of the various assets like the JavaScript and CSS and I push an image to query with this plugin I have a service that exposes it on the cluster so the console will always use this service to get the assets for the plugin and then I have this console plugin resource which we alluded to earlier so this is pretty simple the console plugin just says here's my plugin name, here's the display name and here are the coordinates of the service that hosts the plugin so the service name the service names face the port and any path that's needed to load the plugin so essentially we're just defining hey there's something serving or responding to whatever the plugin needs and here's how to access it exactly, yep so let me create this and you can see the resources were successfully created I'm going to go look at the deployment and it looks like the pod is already running so there is one more step if you're delivering your plugin through an operator when you install the operator you'll have the option of enabling the plugin at that time we do have an extra step where we want admins to be able to decide what plugins are enabled or not so we don't just key off of the presence of the console plugin resource and admin actually has to go enable it so we have a UI for that if I go security function so basically one thing to note is that plugins can run JavaScript code in your console if they can make API requests with a logged in user's account so you really want to trust any plugins you enable because they can make requests as any user who's logged into the console so I'm cube admin here so the plugin can make API requests as cube admin in the interest of security we do want a cluster admin to go in and confirm yes I want to enable this plugin so if I go here to configuration we have all the various cluster configuration resources just fill up to this for console so there's a console operator config so the one in the operator API group here if you click on that there is a console plugins tab and you can do this through the CLI if you want but it's nice that we have a UI for enabling this you can see the demo plugin that I've added and I can go through and enable it here and again you get the warning that the plugin can run API commands as your user make sure you really trust this plugin before clicking yes here so let me save you touched on something there really quickly that I always like to highlight which is the console everything magic per se everything that you do in the console you can do directly through the API directly through YAML the console does add a lot of convenience features exactly Ali you were showing me all of these things that it can do for you but yeah everything that you're doing here is possible through the API straight through YAML yes absolutely so when someone enables a plugin the console will throw up this toast notification and it will say hey there are changes available and this isn't just shown to me this is shown to any user who's using the plugin so basically you need to refresh the console to see the updates so let me go ahead and do that now and now it's loaded the plugin so you can see here there's a new nav item demo plugin and this is really just a sample plugin it doesn't add any real capability it's just kind of demonstrating some of the features that are available through dynamic plugins you can see here it's added a nav section and a number of nav items this particular plugin has some example pages and it's using some of these pattern fly components just to give you an example of some of the things you can do with pattern flying so it's adding various cards to the page alerts at the top of the page you know a hint there are different pages here as well that test different APIs that are available and the source code for all this is available in the repo so I did want to show you one other example so let me drag and drop the other plugin file here and it's very similar deployment here so we have a deployment, a service and a new plugin here for customization plugin this is a pretty simple plugin that I've been working on that actually allows you to use some of the customization CRDs that adds a UI for them so let me go through and enable it we have our deployment running here so I'm going to go back into cluster settings configuration go back to console here I like the click-clack of a fellow mechanical yes, yes let me enable this one and console is going to roll out these updates so this particular plugin and we have a link to this plugin source code as well from the slide deck but this one will add a new customization menu item here under administration it allows you to look at and create some of the custom resources that we get earlier through pure YAML so here's an example so it tries to bring all the customization resources into a list view here it gives you a filter so you can see all the various ones like if I want to look at say the CLI download resources I can filter it here it brings it into one list and it also is I'm working on adding some forms for some of these things so you don't have to use YAML so you can add a because that's as much as I love our documentation that's one thing that it can be spread out all of these different options so it's solidating them and of course adding a nice easy to use GUI it makes life easy right so console links are pretty simple resource but it's nice to be able to just fill out a form and add one right so let me submit one it's showcasing some of the things you can do with plugins you can add list pages you can add creation forms and details pages and all sorts of things I created my new console link here and if I look at where did I put it did I put it on the help menu user menu that's why I couldn't find it there we go example link and it takes me to my example.com page here so yeah so I realized we're running short on time but I wanted to give you guys a demo of seeing this stuff in action so this is something that I think is both inside of Red Hat it's really going to help us as teams contribute and extend the console but hopefully I'll help different people in the community our customers who are using console yeah and I so I posted in the chat a little bit ago and Stephanie followed up with an additional link for the console customization competition that the developer experience folks did I think it was earlier this year maybe late last year so that's just some examples of what's available prior to dynamic plugins I'm looking forward to seeing what's possible with dynamic plugins I don't know if we'll have another competition or not but I've already got some things in my head that I'd love to see yeah nice we could definitely throw another competition and just to reiterate one piece this is very early days this is alpha but it's there if you want to go and actually start creating one there's that demo plugin grab it fork it build your own start using it and if you want to provide us any feedback we'd love to hear what you think so please reach out to us and let us know is it available in 4.9 or do we need to use a nightly with 4.10 sorry I try to unmute myself there are some capabilities that are available the api is pretty minimal in 4.9 and it's still alpha just costing you with that but there are some basic things you can do in 4.9 and you know we're adding a lot more in 4.10 and if you do grab a 4.10 nightly you'll have some more capabilities available I recommend everyone going to 4.10 nightly and starting there better chance of success our hope 9 who's a regular watcher of the stream says that you all are doing great work even for an alpha it looks pretty amazing and I couldn't agree more thanks y'all so Allie Sam do you have anything anything else you'd like to add I know this was super fun to come here and we're like really excited to show this off by the way a big thank you to Maestro Sam because Sam's a legend in our parts so thank you so much Sam for showcasing all this great stuff yes very much so thank you both really appreciate you joining today again this is something that I've been looking forward to a stream that has been on my agenda for a long time so I'm so happy that we finally get to show this stuff off and get to see what it looks like to our audience thank you for joining us today I know we're running a couple minutes over I hope you don't mind so we've been a little inconsistent due to conflicts and stuff like that but the next few episodes or next few weeks we'll have a stream including one Johnny and I are planning on another rush of the disconnected experience which we might turn into a bit of a longer deeper dive so we'll have to figure out what that's going to look like in the next week or two just a warning now that we're talking about upcoming streams we are getting into the holiday season both here in the US and worldwide so once we get into December things will get a little bit jumbled be sure to subscribe to the streaming calendar so the streaming calendar will have all of the dates that we are streaming or not streaming as the case may be so if we don't have one you just won't see a date there and then you'll get those great reminders as well you can also of course subscribe to the various youtube channels twitch etc and you'll get the dings every time we go live whether or not it's the ask an open shift admin show or not so thank you very much everybody for joining this week keep an eye out later this week or early next week for the blog post that follows this up I'll include a link to all of the various well all the links that we use today as well as the slides and I like to put a little table of contents if you will in there of various times that we talked about things so you can link directly to that place in the video so with that thank you very much have a great week and stay safe out there everyone