 Good morning, good afternoon, good evening, wherever you're hailing from, welcome to another edition of our developer experience, Office Hours here on OpenShift TV. We are back after quite the hiatus, Red Hat Summit and KubeCon have been a blur for me, as I'm sure many others, but we are back to our normally scheduled fun. And Serena, you have a very interesting topic on tap today. I find this fascinating. Would you like to tell us a little bit about what we're talking about and who's here? Yeah, definitely. Thanks, Chris. Hey everybody, glad to be back. So today we've got Evan and Ooth who are two members of Red Hat. And interestingly enough, they were both part of an intricate part of the keynote summit demo of developing different pieces. And through that process, we found out that there was different ways that developers were kind of developing and deploying onto OpenShift and testing. So we thought it would be a really cool series for one of our developer experience, Office Hours. So let me quickly let Evan introduce himself. Yeah, sure. I hope my mic's still on. So, hey, I'm Evan Chartis. I work at Red Hat on the managed services side of things. So if you're watching Summit, you would have seen us launch our Red Hat OpenShift Streams for Apache Kafka. So I work with the team behind that and our managed API management solution. And what I do is I'm a technical marketing manager. So I help enable our field and I get to make fun demos. Nice. Thanks, Anuka, how about yourself? Yeah, hi, my name's Ian Lawson. I'm a Domain Solution Architect, specializing in OpenShift. I've been at Red Hat for about nine years now. I basically evangelize about OpenShift and how good it is. I'm slightly different to most people at Red Hat in that I used to work for a living. I was actually a software developer for 25 years, which is one of the reasons why we're having this talk today because I'm an old school software developer who's happening to do new school software development. Okay. Does that make sense? It makes sense, yeah. No, this is gonna be an awesome show. Yeah, so I thought we would first try to do a little pull up front, if possible. And I don't know if somebody could possibly help me put something in the chat as well, Chris. I think I did put. I should be sharing. You are sharing. So here is the question for everybody and you should be able to have multi-select. How do you develop on OpenShift today? So are you pushing to get with no webhook and kick off a build in OpenShift yourself? Are you pushing to get with a webhook so the build's automatically kicked off in OpenShift? Are you building locally, pushing to your image registry, hopefully Quay, and deploying that image into OpenShift? Are you pushing to get building and pushing that image to Quay from CI? Another option might be using Red Hat Runtimes tooling, whether that's Fabricate and NodeShift or is there some other method? So I don't know how many people we have on right now, but hopefully we can get some people to add some answers there and we could see this possibly auto-populate. This will populate live. So let's see if we've got some, I think hopefully we've got visitors back in since we've been off for a few weeks, but it will be really interesting and I'm actually gonna leave this open for seven days so we can come back later on and kind of see where the numbers are, right? If people are watching the recordings. So definitely please take a second to answer that question. And then after this one, what we're also going to do is, which of these have you tried to date? So I am going to try to figure out how do I get out of this? And if I'm gonna remember how to do that. Just minimize it. You should be fine. Just minimize it. Or you can close it too if you're not gonna use it again. I think I might be able to go like this and then the second question will be, which of these methods have you tried to date? So the first one's, which one do you use? This one's have, which ones have you tried? And... Is it multiple choice? It should be. It's not? No. Oh no. Let me see if I can quickly change that. You can fix that, yeah. Hang on folks. Let me see. You never know. I can try. It does say, let's see. Dun, dun, dun. Let me quickly see if I can try to fix this. I wish I knew this interface. Multiple choice. It says it's a multiple choice. They must be. Which can only select one. It's very odd, isn't it? Well, go back to that screen that said multiple choice. Because we're making... Oh, I'm still sharing. Yes. It says multiple choice. Let's see. Right, but is there something else below? No. No. Wait, advanced question, scroll down. No. No. That's weird. That is weird, but you can't select. Is it actually like multi-select? Is that somehow... Yeah, is there like another definition in here? Like hit customize or something? No. That's weird. Really weird. Darn it. So we've already failed before even demoed. So those are hard. Okay. So then let's just stick with that initial question, which is how do you develop on a ship? And so, okay. So this is great. We got quite a variety here. And so I'm not sure who's going to be interested in demoing first, but we kind of have it set up where you guys are going to both be using the same application. We were going to have, maybe Evan, you can go first, explain which method you're going to share. And we can do a little timer. I don't think we have an online timer that we can show, but I'm going to time us. And then the long it takes for each of the methods for the heck of it. Okay. I'm trying to think like, if I go first, is my like Eames is far more flashy whereas mine's more archaic. So yeah, mine's going to, maybe not look so hot compared to his now. Mom, maybe we want you to start first. The flashiness will be. That's what I'm thinking. He's going to be awesome. Let me see. Where do I share my screen? There we go. Desktop to share. I don't want to do it on the start. So has everyone seen that on your screen? So you see my, we can see here. Do you mind just sharing the link within center here? Yeah. I can distribute it out. Chats. Oh, there we go. Zoom chat. Ta-da. Awesome. Okay. Yeah. So far the demo myself and Ian basically put together an application that's fairly straightforward. It's like kind of like a Hello World application. So if you use OpenShift before, you've probably seen some of these and this one is basically a fork of one of those. It's a node one, but I've added in a build step because I really like TypeScript. So that does add a build step which some people don't like but I like Type Safety. So that's what this app is. And Hello World of TypeScript on OpenShift. So let's see how I'm going to deploy it. So I'll give a quick overview. I have this phoned locally and how I plan to deploy it first. I have a few different ways actually, but the main one I'm going to show I think because this is what I was doing at Summit that had the disconnect between me and Ian is I'm going to build it locally. So here I have what's called an S2Y script in my folder or in my project and all that's doing is using S2Y. So that's a tool that Red Hat provides and it stands for source to image and what it does is it takes your source code and you give it a builder image. So in this case I'm giving it the Node.js builder image and it will transform your source code using kind of best practices like the standard procedure you'd expect with most of the runtimes the same. It does the same thing with Java and other languages too. And it's going to transform that source code from a local folder into a container image using Docker or if you use I guess a builder and podman it supports those two I'm guessing but it builds that container image on my local machine and I'm going to push that up to key.io or you can push it up to a different image registry if you use another one and then I'm going to deploy it on OpenShift. So I guess I'll do that. I'll dive right in. I have an OpenShift cluster over here by the way in Chrome. So I'm just going to deploy it into this dev project I have here. This is a free cluster by the way. You can get it on. This is the sandbox. Yeah, I love it. It's so cool. It's like how easy it is to get these clusters. So maybe we can show that in a minute although I'm sure you've shown it before on the channel. So yeah, let me dive right in. So we're going to run the script and you see it build. It should only take a few seconds and I'll deploy it on OpenShift. So I'm on my terminal right now and the script is going to do s2i.sh and this will invoke s2i and it's really quick actually. I have to copy my source over to the build container that it's spun up in the background. So if I like go to Docker PS, it's probably going to say, yeah, there you go. So I have this container spun up and it's building my source code and it's going to output another build image on my machine. So it takes a few seconds, but while I do that, maybe I should put the link to source the image in the chat for us. Would that be a good idea? Yeah, let's share with everybody what source the image is because there might be new people watching. So like if they've been using OpenShift for a while, I'll know this, but I'll put it in here. And yeah, you can see it's just a CLI you can download. I usually download it directly, but if you use package managers, it's in I think most of the major ones too, like Bru for Mac, for example, and probably DNF and Act for other platforms. So yeah, let me switch back over here. The build is almost done. So because this is a JavaScript project, someone's going to make an MPM joke, probably, download the internet. I have a meme for that. It's like Maverick. Yeah, pick your poison, right? But yeah, so that installed the dependencies and it ran the TypeScript compiler, which compiled my TypeScript to JavaScript. And I know if I do a Docker images here, there you go, right? So tag this with this really long tag name that I've given it, which is key.io. And then my username and the overshift example. So what I'm going to do now is push that. So Docker push. So this is quite manual as you can see. I'll push it to the latest tag and key.io. Nice. And hopefully it doesn't take too long. Awesome. The timer's going. No, I'm doing so much explaining here. I'm not helping myself. So if I refresh your key.io, you can see a few seconds ago, the latest tag was updated, which is awesome. It's ready to be deployed. So I'll go over here to OpenShift. And I like this developer view for doing this stuff because it gives you that nice topology when you've deployed a few things. So you'll see that now. So I'll do an ad. I'm going to choose container image. And I know it's... Oh yeah, I can just copy it to my terminal. Right. Rather than typing. I've got to save time. So I'll do that. And I better say the latest. Just in case. I would say it's an OJS app. So OpenShift lets me select that label or icon. The application name. I'll just call it. Yes. And then I'll call it my OJS server. If I can type it. And I generally actually choose deployment config for this stuff. I don't know why it's just Havish. I know deployments are maybe better. But I'm just so used to the point configs and how to do the rollout. I just prefer to do that. And then forever. I'll make sure it's using HTTPS. Direct HTTPS. And now to create. And after a few seconds. The app is deployed. So I'm not sure when we stop. Stopwatch. Stop it when I open the endpoint and it like. It displays. Successful endpoint. Right. You can't have a 500 error or something. No. Yeah. Okay. Let's see. Okay. And I didn't start it until you ran your script. Ah, you're very kind actually. So. Yeah. You're being nice to me. It's good for explanation. Right. Let's see. There we go. All right. So you were about three and a half minutes. Just about. Just kind of cool. That's not the fastest. I think I think Ian. Ian's like got skills. He might beat me here and his. He's building on an open shift. So. It's probably going to build even faster. But it's going to be a little bit faster. So let's see. Let's see how long it takes. And then later on maybe we can do a, Hey, what are the pros and cons of the two? I think so. And I have a lot of other methods to show off. If we get there. But yeah, there we go. We have a nice little. Type script. No JS application. Awesome. Thank you. All right. You want to go next. No. That question. Let me share my screen a minute. So can you see it? Yes. Yeah. That's good. Yeah. So before you start the timer, because first of all, I didn't realize there was going to be a timer. Which is a little bit of a pain. A very quick introduction about why, why we want to do this in the first place. When we were developing on summit. When we were developing on summit. When we were developing on summit. When we were developing on summit. When we were developing on summit. When we were developing on summit. When we were developing on summit. When we were developing on summit. When we were developing on summit. When we were developing on summit. I was just using the open shift side because that's what I'm used to, you know, I've been using open shift for so long and I really love the open shift user interface, you know, it's it brings my bells, you know, I'm a bit of a pattern fly addict. But I was very surprised that all the other developers that were involved with summit didn't use the actual open shift to do their builds, they were doing all the builds locally, they were using Docker, you know, the same way that Evan just did. Right. So I used Docker. I have a history with Docker, which I won't go into because I think a lot of us do. Yeah. Yeah. I'd be told not to swear. Fair enough. See group nightmares. Oh, it's not so much that I love my Mac and Docker doesn't love my Mac. So every time I try to put Docker on my Mac, they just didn't get on like a house on fire. So I don't run contours locally. If I want to do builds, which I had to do some builds like this at summit, I've got a virtual machine running for Dora and I use pod map rather than Docker for that. But for things with the applications where you can actually build within open shift itself, all those things that Evan showed you in terms of the source to image, they're all wrapped up as part of the developer experience within open shift itself. So, whilst it's nice to be able to download the S2, I use it on a kind of local machine. I like to run my builds elsewhere. You know, I've got other things I want to do with them with my CPU with my with my with my machine itself. So I found myself using open shift to do everything. So what I'm going to do. And if I'm lucky, I can just sneak start starting without three actually starting with the timer on it. What I'm going to do is I'm going to do exactly what Evan did, but I'm going to do it all through the user interface. Nice. And also I'm going to I'm going to add Redis. Just just because. Yeah, we're all friends here. We're all honest. I didn't see this application till this morning. So so I've never built it. So so this this goes down. If this cat is fire then. This time. So I may have. I may have rigged the game here with this application in. I'm not going to tell you about all the secrets. Yes. The competition was real before we even started folks. Yeah. Yeah. I'd like to say I'm a fan boy of open shifts and people people who know me know I am a fan boy of open chip. But anyway, so I'm going to do it from scratch for the user interface itself. So the first thing I'm going to do is I don't have a project. So I'm not sure if you're going to start at the time. I'm going to start a project. I'm going to start. I'm going to start now. Let's see. Now counts. Let's call it. Hello there. Going to create it. If I pop it was the developer viewpoint. Same topology we had before. I'm going to do it from. Not the container image. I do it from the catalog. Now the application itself is based around node. So I'm going to use a NodeJS builder image. Okay. Create the application. I'm going to choose 14. Was it 14 or 12? You built it with. Evan. I did a 12 but it should work with 14. Yeah. I'll see here. You can house a slur if you want. One more time. Now we're being sneaky here. I'm going to take the GitHub repo. Copy it. Put it into the repo itself. Found the dates. I'm going to use the same thing. Deployment config. I prefer them to deployments. Give an application name. I'll call it demo app. That's for the application grouping. Not the application itself. We'll call it test because I love using the word test. Create a root. Yeah. Exactly the same. Hit create. So how this is different to the way that Evan did it. This is actually creating another pod. Before it even starts to do the application deployment itself. It's going to build. So all the things you saw Evan do on his command line, on his local machine are now being repeated, but they're being repeated within a pod, within OpenShift itself. So I'm using OpenShift resources to do the build. And we can actually look at the build going while it's doing it. And you'll see exactly the same kind of messages that you saw from Evan's side. Something about Husky. It complains bitterly about Husky. It's like, it got to the NPM stage and said, Husky is no longer supported and you're a person for using Husky and all those kind of things. So yeah. So what it's actually doing now is it's downloading the image, the base image on which it's going to build. So it's going to get what we call the universal base image. Universal base image is a very useful tool. It's a very useful base image that we've produced. That's designed as a kind of small, easy way to actually build applications on top of. It's going to get them. It's loading them into the integrated registry before it starts to do the build. When it's got the image down, when the image has actually been produced, it'll actually start to do the binary build side of the actual application itself. I'll hit resume stream so you can continue to watch it. It will bit about the NPM stuff. And someone complained about NPM timing. I used to do, you know, all the demos I did for about two years were based on Java. I used to sit and I used to have to make up things and talk to customers while they're downloaded for 40 minutes. You know what I'm saying? How fantastic the system is, how fast it is, and all these kind of things. It's got 40 minutes of bloody class files being downloaded. Anyway, that's what we're doing. The kind of stuff that Evan was talking about. And there should be an error at some point. It talks about Husky. Because it's scared seven times of crap out of me when I did it before. Yeah, I really need to look into suppressing, though. I thought I had a suppressed file. This is really interesting because we're at 308 right now. Oh, and? So it's finished the bill, but it's produced the image, the image has been pushed into administrative registry. It's now deploying it using the deployment config. There is something else as well because Evan cheated. Oh, it's done. Hit the link. Hit the route. Hit the route. See, Evan cheated. And the reason I was saying, Evan used off. Did he click the route? Sorry. Did you click the route? Okay. Well, I stopped as soon as. There we go. There we go. Which is the same thing I did on the other one. So it's 325 versus 332, which is just interesting. Seven seconds of savings over a year. That adds up. The first thing is, I forgot to press the open URL button, but the second one is. Evan is using the dedicated sandbox, this new sandbox we've got, which people can range, which is fantastic as a hosted system. It's a grunting, meaty system. Now I'm not allowed to use it. I am, but I'm not allowed to use it because I'm a red hat employee. So I've got this, this, this sort of lesser cluster, which I've run up on AWS, which I've got limit ranges, which means that all the pods run much slower and those kinds of things. But being serious for a second, you see that exactly the same functionality, but I didn't have to fire up a command line. I didn't have to do as much typing, which, you know, when you reach my age, you know, less typing, the better. But the nice thing for me was that I could track and I could see everything that was going on from a single point. I didn't have to go off to a different page. I didn't have to go off to a different command line. Didn't have to go in different sort of perspectives. The topology gives me a wonderful single point view over everything I need for this. And it's really, really nice. And if I got time to do a couple of additional things on this demo. Sure. Of course. We don't have a new show today, so please feel free to go over. Add the Redis. This is all Evan's coolness because he wrote this. So what this application does is it actually uses Redis to count the number of times of which the web page is an old school web page counter, which I haven't seen in about 25 years. That's what stood me while I looked at this. I thought, yeah, it's a page counter. It's like GeoCities or MySpace inspiration, right? Right. Now, I remember there was a site that, like, that was all the analytics you could get back then. It was just this little thing that just incremented as people loaded your page, which meant it was mainly you. Exactly. You refresh your own page, right? People still use Mosaic, right? I'll just check it. So what I've done is I've added Redis to it, but it isn't currently wired in. Now, one of the nice features that you get with OpenShift is when you add things in the namespace, add applications themselves, each of the applications can express environment variables into all the other pods, but they're not expressed until the pod is restarted because, of course, the environment variables are part of the container, part of the container spec when the actual pod starts. So I'm going to restart this now. It should pick up the Redis thing. And again, this is going to fail. I was going to do the kind of, oh, dear, it's failed. That kind of sort of wonderful thing we normally do, but no, no, no, this will fail, but I'll tell you why in a second. So I'm going to do it the old school way. Let's get it down to zero, get rid of the resources, scale it back up. Theoretically, it should start up and have the Redis database, the Redis sort of backend storage so it can actually record the number of things. And it's immediately failed. It's a lovely good old fashioned red, wonderful crash loop backoff that we're aware of. And the reason it's failed is that Redis is authenticated. It needs a password. So even though the actual configuration information, the connectivity information is expressed automatically into the deployment, we haven't got that piece of information. Now normally this will require me going away, following the command line, looking at the secrets, changing a config map, doing all those fiddly things. But another nice feature of the user interface is that I can change the aspects of the deployment of the application as well as the application itself. So what I'm going to do, and I'm going to watch Evan Wintz because I'm probably going to get it wrong, is I'm going to look at the deployment config, look at the environment, and I say I'm going to get it wrong because I got it wrong earlier. I'm going to add from a config map because the config map actually for Redis contains the password. It's part of the thing. There's a secret that's mapped into Redis that contains the base password for getting into it. So I'm going to create it with a name, and I'm going to get this wrong. I'm watching, I'm watching you. Can we just stop here or carry on? Oh, you've got too far. You've got too far. Right, sorry. Pass, not pass. Yeah, it's pass, yeah. Okay, got it. That keeps it beautiful. You see, with host and port, they're all four letter words. You've got to have, you know, your OCD. Right. It's got to be just right. This is another thing amazing about the Summit Development Teams because everyone on the development team is 30 years younger than me, right? And so, so I come from an old school where, you know, when I first started programming, I used Fortran, and Fortran was a horrific language where you had to tab and space, and you had a limit of six letters or whatever on the actual variable names. When I started to learn Java, I wrote the most verbose code you've ever seen because I could. I wrote sort of five pages of Java dot comments, you know, because it was just wonderful to be verbose. And yet everyone I dealt with on the Summit Team was writing these sort of four letter variable names. It's like, come on. Enjoy your typing. You're allowed to do it. I'll set the key from it. Database password. Database password expressed in the secret as part of the Redis distribution. Nice. I saved that. What's nice because it's a deployment config, it's going to detect the configuration change for that application and redeploy it. When it redeploys it, and I've got my camera on so you'll probably see my fingers across, it shouldn't crash. So it isn't crashing. And the reason it's not crashing is that it actually has those environment variables now. It actually expressed into it, including the password. I'll show you it very, very quickly to show I'm not faking. You should share the link as well, Ian, so we can all increase that view count for you. Ooh, yeah. What link? The link to the web page. Which web page? Sorry, sorry. I'm having one of those moments. Yeah, there we go. Okay. So send us that link or bump up the numbers. Yeah. I'm not sure I can. I don't have access to chat when I'm sharing a screen. No. Just drop it in the Zoom chat. I'm not on Zoom. You're not on Zoom. Let me unshare in a minute and I'll share it. Yeah. All right. I want to show you very quickly the environment variables that you see within the pod itself. So what has happened is when I've added another application into the namespace, there are certain number of environment variables that are automatically propagated into the environment of the other pods that are running. So when I actually installed Redis, you'll see if I do an environment and I grep Redis, I've got a set of wonderful connectivity information for that Redis pod. And that's not part of this application. That's not part of the image. It's actually being injected as part of the deployment config. And that's the wonderful feature about developing with the OpenShift user interface is that you can see all of this and you can interact with it directly. So does that make sense? I mean, I know I've gone over the three minutes or so. No, it does. It makes total sense. I've also got OCD. And this is where Serena starts to win. I love the topology page because I come from OpenShift 2 background. If anyone remembers OpenShift 2, if any of you are old enough to remember OpenShift 2. And I loved OpenShift 3. And then when we released OpenShift 4, we didn't have a developer user interface. And I thought, why does Red Hat hate me? And then we got this one, which is absolutely beautiful. But one of the nice things about this is the application grouping. And I think I'm one of the few people, especially on the Summit team that went out of my way to OCD the application groups. And it's all done through, interestingly enough, the labels. So if I go to the DC, for example, look at the details of the DC test, if I edit the labels themselves, you'll find there's one in there, which is app.kubernetes.io.partof. This one here. I'm going to cheat. I'm going to just go copy it. Sealing my mackerel at me. Come on, baby. If I go into the deployment for Redis, go to the details here. Edit this. Add a label. Add that one. You can also do that by like the drag and drop with a shift. I'm still getting used to using a mouse. This new fangle thing called a mouse. Yeah, I see that there's been a lot of enhancements lately with the topology page that I find really, really useful. I do love it. I think I may have asked for this. I love seeing the podcasts and I was missing it when we had the original topology page. Anyway, I'm aware that I've been talking for a long time. Is it someone else's turn? No, that was great. Actually, do you want to share the account? Did you want to share the account of that? I mean, the URL? Or have we lost that opportunity already? Well, as soon as I stopped sharing, I was going to run Siege. I was going to do exactly that when you were there. That's why I wanted the URL to like a patchy budget. But then I remembered it's my poor little cluster. That's exactly why I wanted the URL. So Evan, did you want to show another, an alternative method? Yeah, there was two more. Yeah, there was two more. I think a pretty cool more shown. So let me, I'm going to assume the screen. There we go. Okay, I think it's working, right? Perfect. Yes. So there's two other things I want to show. The first is the, so the tooling that we have a red hat for different runtimes, right? So red hat has runtimes. We support, as you can see, we have the supported container images that myself and Ian used, like the Node.js one, but we have those for different runtimes. And for, I know at least Java and Node are the two I use the most. We have, in Java, we have a thing called fabricate. And you can use that to deploy your Java apps really easily from using Maven. And for Node, we have the same thing. So I want to show that real quickly here. So if I go back to the code base here and in my dependencies, I have this Node shift CLI installed. So this is the Node equivalent. If you're familiar with fabricate, it's kind of similar. It lets you do some neat things with Node on OpenShift. So yeah, if I wanted to, for example, I can go to my terminal here and I'll just make sure that I'm logged into my cluster here. So yeah, I'm on eShark as dev. I'll change to a different project for this one. So I don't clutter things up. I'll do an npm run, Node shift. And this is actually kind of interesting because what? Uh-oh. Why did it break? Did I mistype it? Oh, I need to do an npm install. Oh, well, there you go. Yeah, I'll do it. Every time. And hopefully it's quick. But basically this is really interesting because what Ian showed using the CLI, sorry, using the UI where he did that, set up where he used a build config and that trigger to build and built the application on his OpenShift cluster. Node shift does the same thing with one CLI command. So it's another nice way to set up that whole workflow. So you can see here. Yeah, it's super cool. You can see here it creates the image stream. And then it's uploading the archive of my local directory, which has my source code. And you can see these logs that are really similar to what was on Ian's screen. So if we go over, yeah, it's really cool. So I love this. Like to go over to stage here in my other namespace, and I go to builds. There you go. Like there's a build created a few seconds ago. And you go to this build itself. And you can see it's only on the first build obviously, because I just created it. And I can go in here and take a look at the logs. And it's just working like that. It's so easy. So like we don't just have UI tools to do that. Either we've both, we've CLI and UI. So when you move or graduate to say, wanting to do this from a programmatic perspective, you can do that too. Or of course you can use QCTL and OC to apply YAML. If you're doing that in your CLI pipelines too. But it's really easy. So you can see the same logs that Ian was on about where he kind of gives warnings about some of the dependencies. This is an old template that I have from a while ago, but it will finish building. If I go with my topology view. Oh, wait, yeah. So what's interesting that this one is it doesn't build, or sorry, it doesn't apply the deployment convey come from the build finishes. So that's why you're seeing nothing in my topology. So what we have to do is we have to wait for this to change from status running to completers. And then also guessing you're on sandbox you said. And it's sandbox. That's right. So in, and which is, I think it's still for six. So in four, seven, you'd actually see the empty topology view rather than that. Add page as default. If anybody's interested. So there we go. That's it. Yeah. So that has been up in a moment once. The image is pulled. And there you go. So if I click on the link. It might take a second. Yeah, it's not. Yeah, you gotta wait for it. Doc blue. Yeah. Yeah. Oh, you're just trying to win now, Evan. I'm just trying to be really fast. Yeah. And you might. Yeah. There we go. There you go. So that was, so that was two 14. That was significant. Interesting. So that's significantly quicker. Yeah. Yeah. Because you're not like clicking stuff. I guess you can do it a little quicker. And that note shifts. If we go back here, you can see it output the same logs that we saw in the UI. So it's mirroring. The, the logs back to your terminal. So it's a nice little note shift in my life here. So that's very crucial, right? For real. This is awesome. And look, if you would feel like, so if you're familiar with node tooling, you have this nice MPX CLI. So that will call my local copy of no-shift in my node modules for this project. And you can see it has tons of options. Like you can specify your OCP credits or your credentials to login. But you can also, you know, manage if it uses, if it exposes an SSL endpoint instead of just playing HDTS or main HTTP, you can specify the image stream, all sorts of stuff. And also, you know, the pretty display name. So name space. So it's like, it's really powerful too. And it also supports, I haven't really looked into this one yet, but you can create a .nodeshift file in your project. I think it reads from there. So if you want to make customizations to your deployment config, you can do that. So it's really neat. Like you can put in custom environment variables and different things. So yeah, it's a lot of fun. The runtime scene, like the note team, they're doing cool stuff. The Java team, like Quarkus team, like they've all these cool, similar tools that really make it nice for a developer when they're either staying in local or going to UI, they can use these in conjunction. But for example, it's really quickly, if I was using node shift, for example, I can go to UI here and I have to confess, I do this all the time. So I go to the edit deployment config or deployment. When I go to this YAML view, I copy and paste this all the time as a template for my YAML when I want to do like CI deploy. So I always make, I don't know about you guys, but I can't write YAML. I just always make mistakes. I never know like, should I put a, you know, just- Base tabs, yeah. Whereas with XML or JSON, I'm like, okay, like I know where I put my brackets and I know where I don't put my brackets, but with YAML, I just have no idea. So I do this all the time. I deploy using UI, like in showed, or I use node shift or Maven, and then I copy the resources and then I recreate the project with those in the future in CI. So- So we have a question here. Can you use node shift to deploy node-based open shift crown jobs? That's the question. I'm not sure if I saw crown jobs on that list of options. I don't know. I don't think so. I think it's mainly like deployments I think- Great. And my job could be a future request though. You know, a crown flag, right? I dropped the link to the repo. So please open an issue. It's a good idea actually. It is kind of a good idea. Yeah, you can script something up in nodes so quickly to do, you know, a fetch, pull a resource, and check it for something. Yeah, anything, yeah. Yeah, so that's actually a good question. Something through here. No, I'm not seeking anything for crown, yeah. So that's cool, okay. One more thing if I'm left half the time. Yeah, we still have about 18 minutes or 20 minutes, yeah. Awesome. So what I'm gonna do is open the code base locally here. And I'm just gonna make like a trivial change. So I'm gonna go to the index file here. So I'm using handlebars for templating and we have a rocket ship here, which is a very cool emoji, but let's change it to like a rock star. How about that? Like a lady rock star, something like here, right? An easy change. I'll do a git status. I have to play a few things, but I'm just gonna get add the views for now so I don't break anything else. Commit that. So, yeah. Feature, use cooler avatar, cooler emojis. And so you can see husky here that we were getting mad at is being really good to me because it's formatting my code and keeping it consistent. So that's why I like husky a lot. It keeps me disciplined and keeps my code like format. So if I'm sloppy, it doesn't get checked in without this weird formatting issues. So husky is a new one on me. What is husky? So basically it's a library you can pull in from NPN. There's probably equivalent for like different runtimes, but what it does is it installs githooks in your project and you can link them to scripts in your package.json. So for example, I'm using husky and I have a block here in my palm or my package.json and I put in a pre-commit hook and basically what it does is I'm saying run my format script. So format my files. So, it's JavaScript. So you could leave out some of the colons or you might want to put them in or take them out or whatever. So it runs my formatting and then it adds those update files into my commit. So it's really nice. It basically, you can do other things. Forced it to run unit tests. So someone can't make a commission unless they run your unit tests and other things like that. So yeah, it's really neat. But weekly downloads, 5 million. Yeah, it's a lot of people using that. It's very popular, yeah. And actually the way I'm using it here is technically wrong, I shouldn't be using stage. The way I'm adding the files and format is not right. But what's really cool is I'm integrating github actions in this project. So we didn't talk about CI or CD much yet, but I have a workflow here that uses Red Hat's actions. So Red Hat has these really cool actions on github where if you go and check out this build, I have a sourced image action. So the sourced image I was doing on my own machine or myself and Ian both did on OpenShift, you can run it here in github actions too. So you look at these logs or the exact same logs because it's running the sourced image binary on github actions. And then after that, I can use the pushed to key or query action. So it's taking the build images from github or the github action pushing into my repo in key.io. So I didn't do a build manually at all. So you've so many options here to get this S2Y into your workflow, right? It's really cool. And these actions, I set them up last night because I've seen them before, but I've never used them. And I was like, it'd be really cool to finally use these. And it's so easy because we just copy a snippet from the action documentation that the Red Hatters have built and just worked basically, it was so easy. So if I go over to key.io now and refresh, you can see a few seconds ago, my latest tag got updated and I've a new tag here for that specific commission. So it's so easy. And then if I want to just redeploy this, I can go over to my dev project because I have my dev project pointing to the latest tag. And I can do a rollout, or I could delete the pod as well, I guess. But if I start this rollout, it's gonna pull in the new build and after a few seconds, spin off. And hopefully we've got a rock ceremony. Let's do a refresh. Oh no, did I mess it up? Maybe. Let's see it. Let me see. Let me make sure it was pointing to latest. Ah, it's off. So it imported an image from the new tag. Yeah, it did. Let me fix that. So that's just key.io slash my name and we'll pull that in and get the rock star emoji. Latest. Okay. So now it should like Ian showed earlier, do the old match replay, I hope, but if it doesn't, we'll just trigger a rollout. Oh yeah, nope. It's already doing its own thing. Look at that. Awesome. Refresh and hopefully we have a rock star now. If not, demos be demos. Ah, it's not working. I obviously made a mistake somewhere, but you get the idea that it did the build, right? And checked it into key demo. I'm just after making a mistake here where I'm pulling the wrong tag or something. But yeah, pretty cool, right? Very cool. That's very cool stuff. Yeah. So curious on what people think are pros and cons. Does anybody want to advocate for one over the other? Who do I think I know which one you would advocate for? Yeah, always. Which I love. It's a nice user interface. It's very rare as a developer you get to use a nice user interface. That's true. That's very true. I think so too. I've had years of Eclipse and Jbuilder and Visual Studio and Visual Ball and all those kind of wonderful things. So yeah, being serious for a second, I always found when I was using OpenShift 2 and OpenShift 3 that there were things I had to break out of the interface to do. And when you're actually trying to code something very quickly, when you're trying to get something done very, very quickly, you don't want to be shifting around. You want to have a nice single focus. You want to be able to focus on your code, focus on what you're doing. And I find it's much easier to sit with just a single webpage open. And I can go and I can see what's going on, find the problems, find the events. Was that the Rockstar? It was, but that was locally. So I know what's going on. Yeah. I just messed up my deployment on OpenShift. I was just trying to sort of feed it into you. I was like, ah, it's working now. I found, especially in the latest couple of releases of OpenShift, there's been a huge amount of functionality added that makes the developers' lives easier. I've had lots of conversations with Serene in the past about the kind of workflow, because oddly enough, most of us cheat. Most of us will develop locally, we'll go and build the images the same way that Evan was doing. And I think people need to be aware you don't have to do that anymore. You can do everything. You can dive right down. For example, the stuff that Evan's showing right now, literally before this, just before this stream, what the reasons were, I'm mildly confused, is I was dealing with a problem the customer had. And we were just diving straight into the amul. Literally straight into the amul to find the problems. And it was like, fix the amul, fix the amul, fix the amul. Needle and haystack, yeah. Yeah. And we didn't have to leave, we didn't have to leave the user interface. We didn't have to, because the minute you leave, the minute you go somewhere else, your brain is shifting. You know, you're thinking of something else. Your context switching, yeah. Absolutely. And I had a similar problem when I was working on Summit and I can talk about it now because it's all done and dusted and it didn't catch fire. Where we would find a problem where we'd have to jump into another system, jump into another cluster, jump into another system. By the time we get to the root problem, the root cause of the problem itself, I'd forgotten what the problem was. You're something layers deep. Never good. You're too deep in the layers. I ended up cheating on having a post-it pad and I would write down sort of context to see where am I being or what I was doing. Because by the time it was like, oh, we've made it red. And it's like, what were we trying to make red? What was the goal here? I forget. Yeah. It's one of those things about OpenShift. OpenShift is all about efficiency and it just makes everything about it. The way you can deploy applications, the way you can use your infrastructure, the way you can write applications, but it makes a developer's life easy. Yeah, I think too, like there's different ways to do that too, right? We've got the visually guided methodology now and through the topology view, which makes a lot of things super easy and Evan had demoed some of that as well during the summit keynote where he was doing for the binding, right? To create the binding and stuff like that. But we have a lot of methods like that, but then there's still, for people who are more advanced and really want to still touch the end, well, they can, right? Because there's definitely people who are well knowledgeable. I mean, I'm like, yeah, exactly. I feel like, I also think it's interesting as a kind of like learning paths, maybe. I'm not sure is it like learning path, right, Char? But like, it's not even that you graduate from one to the other, but I find like the UI makes it much easier to like get these concepts solidified in your head, right? So like, why do I have deployment configs and how do the pods relate to those and the builds relate to the pods and the images? Like there's loads of moving parts when you start using Kubernetes and when you start using OpenShift, but having this UI and the fog view and those nice like labels, it makes it much easier to learn. So even just from a learning perspective, it's nice. But also when you need to make quick changes, it's so much nicer sometimes than having to like, you know, write some RK command with patches for labels and stuff. Like you just, you know, you can go in here, open up your build config, go to your YAML and make the change so much easier. Like I, OCPatch commands, I've messed those up far too many times. So, or like, you know, it just, I really like UI just from doing these administrative tasks and getting started on, I think the UI just, it's one of our nicer features in terms of just as a developer getting started with this stuff, making it feel less intimidating, I think for sure is really nice. And a couple other things that are coming in the future, because I am serene in the future. But we will be having form-based edits for deployments and deployment configs very soon. And then possibly the release after form-based edit for build configs. So again, like you're showing that and jumping right into YAML, but like if you prefer a form, we're trying to get some of that, some of that back into OpenShift 4.x because we did have form-based edits in three. So it's another thing we're trying to do from a parody perspective. So one thing I noticed that's interesting, Chris, is that the China is super quiet today. It is super quiet. Much more quiet than YAML. But there's a lot of people on. But there's a lot of people on. So are they so interested that they don't want to ask a question or what's going on? It would be interesting to hear if other people have different methods that they use or anything like that. And if not, I'm sure we can still talk, but. Yeah, Sahir asked a question about his having problems with a VMware install. Did Ian mention he also writes books in his spare time? Oh, for God's sake, that's Anthony, isn't it? Yeah. I love it. I love it. I love it. He's a fellow solution architect. Yeah, I write books when I'm not writing software. I also very like that. Oh. Sorry, I would talk more about it, but I'm getting some at flashbacks from looking at metrics. I desperately don't want that CPU on to rise. Yeah, yeah, that was a good time. Does a pro and con exist for most of the recommended new projects and add to projects? Could you, that's a question that's being asked. Groove CS, can you maybe elaborate on that? Like a cheat sheet? Okay, yeah, yeah, yeah. Do we have any cheat sheets about deploying to OpenShift or anything like that? I feel like this episode could spawn a few. So actually, that's a good idea. It is a good idea. Correct me if I'm wrong, sorry, but don't we have quick starts? We do have quick starts. We do have some quick starts that are limited yet right now, and actually the quick starts, if you go to whoever's sharing their screen, if you go up to the help menu on the top and the first item under there should be quick starts. So there are a number of quick starts that are there by default. And the really cool thing about quick starts in 4.7 is that they're a custom resource, so any admin can provide their own customized quick starts as well to ensure best practices or whatever they wanna recommend for their own developers. So that's kinda cool. And so this is interesting. So I think somebody just wrote, yeah. So should be using git versus dev file versus whatever and all great questions. And I think what we have tried to do inside of OpenShift on that ad page specifically is enable options and then allow that cluster admin to kinda lock down things when they see fit. When we get to 4.8, you're gonna be able to see that on the ad page. The cluster admin is gonna be able to hide pieces that they don't want available for their devs. But what I guess it would be interesting to have a conversation from a Red Hat perspective or from specific developers or essays, what do they think is the best practice? That is okay. Oh, don't ask essay. Well, I'm sure we could get a lot of opinions. Yeah, we're going to be. I said, I have a problem with that. I think that was beige. Ian was like baiting them into actually giving their opinions. I have a slight problem with that question because this is one of the things I talk a lot to customers about. OpenShift is a box of technical Lego. And one of the wonderful things about OpenShift is that if you want to do something, there's probably four or five ways you can do it. We don't push methodologies. We don't push opinionation on people when they're using OpenShift. It's designed to cater for other people or what other ways of doing it. I get asked all the time, what's the best practice for this? What's the best practice for that? And it's, well, what's the most efficient practice for the way you do things? Yeah. You know, it's much nicer to give people a box of technical Lego and let them build their own models and give them a model and allow them to change the lights. Yeah, having some blueprints along with the Lego I think helps a lot. So when you have options, you can build your own customisation from that blueprint, right? That works for your organisation. I say it's why I love templates so much and why I'm happy that templates didn't go away. Well, and somebody also mentioned Dev Files, which is another piece where, again, in the future, you're going to see that coming out a lot more inside of the Dev perspective, which is, again, another really powerful piece that we'll have in the portfolio. So maybe we can have a session dedicated to Dev Files, actually. Yeah, it might be good to do that again. Do we have any news on the forthcoming build stuff? Out of interest, this is out of curiosity, because, you know, I love build configs. I love the way the build configs work. We were talking about builds V2 at some point. Are you talking about support inside of the console for that? Yeah, well, I'm just worried about when I have to learn it. Yeah, you're going to have to start learning soon, but it will be phased. Yeah, there's no formal commitment out in the public for one that's going to be coming into the console yet. But we are working on it as we speak, so. Cool. It's password, by the way. Oh, is it password? Password, yeah, not password. Can't get me. So there's a question here. Can Dev Container, something from Microsoft, files be created? Can Dev Container, something from Microsoft, files be transformed into Dev Files or used as is? I have no idea what a Dev Container file is, to be honest with you, so. I don't either, and I'm wondering if we have anybody in the audience that might be from the App Services Team working on Dev Files that might be able to jump in. I don't know. I was going to give a pithy answer, but no, I won't. I mean, having been a development developer for five years, I really sort of, no, I love Microsoft. Yeah, I mean, I think it's great that Microsoft is doing everything they're doing in the open source space, but yeah, I've not heard of the Dev Container reference or something like that now. I think it's there, is it there, like, similar to the Code Ready Containers, right? Yeah, it looks a lot like a Dev File or whatever. I'm not sure, like. Yeah, I think it's very similar. Did you see it start, Evan? Yeah. I'll get it overnight. Over 9,000 now, right? You got to see it. You got to see how far you can go. How you can go before someone starts to complain that you're damaging the dedicated cluster. I know. So I think if it's okay, I'm going to share my screen super quickly, which is just going to say, hey, based on what we just showed now and what we've talked about, and just to get an idea based on after we talked and showed everybody. So let's see if I can actually find the screen that I want to share. There it is. Let's try to do a Presents here. And I think we only have two minutes left anyway, as Chris, but maybe we can get people to answer this question. And again, we'll leave this open for seven days just to get some feedback based on anybody watching this on YouTube later on. What was the link to this one? I forget. It should be the same link. Let me see. Give me one second. Oh, you're fine. I think I can come over here and say share and get the link. Yeah, I got it. You got it? Okay. All righty. That's not the right one. Let me know and I'll paste it into the chat. Yeah, go ahead. Okay. Looks like it's working. Did that one just vote for no chip? There we go. I promise I haven't voted. I want to keep the poll pure. Evan threw in a sneaky one at the end here. Now I'm just kidding. No, this was great. It was great to see the, you know, we only shared three of the methods, but it was really nice to see just the variation of options. If nothing else, it'll give people an opportunity to go think about maybe trying some of these. Yeah. Like, no shift as a game changer, I feel like. So, working with Node on OpenShift is now way, way easier. Yeah. Yeah. So I want to thank both Evan and Uth for coming. This is really great. I'm glad you guys joined us and glad we were able to bring this opportunity to share some of the work that you guys are doing and ways that you're accomplishing things. So thanks very much for your time. Yeah, I really appreciate it. And thanks to the audience for tuning in as well. Yes, as always. Yep. Yeah, this poll is going to run how long you said seven days? I keep it open for seven days. Yep. All right. So yeah, feel free to answer that poll if you're watching this afterwards. Okay, the 11th or the 18th is when it will close. So feel free to watch it until May or answer it until May 18th, folks. By the way, I should add, if anyone's wondering how to fix the error run into make sure you update your image stream. That's what I forgot to do. There you go. I just, I was like, I remembered when we were talking there I was like, I never did an OC import image to like update the image stream. So if anyone is saying awesome show, good session. Ian, there was a special shout out for you. Great, great to be here. You're so funny, Ian. That was from somebody named Linux Studio. So maybe you know them. I don't know, maybe that was a plant. Maybe. As always, thank you all for joining us and we really appreciate it. If you want to see more of us on a regular basis, please subscribe to our streaming calendar, which if my mouse would work, I could open that window and type in the shortcode. There we go. And you can catch us every week doing stuff like this, every day almost doing stuff like this if you so desire. So please tune in at the next available opportunity and let us know what you want to see. You can always email me at shortatredhat.com and your show ideas are useful to me and the rest of us. So thank you very much everybody. It was great to show today. It was really good. Did not know how it would go, if it would be a crash vest or what, but you all did great. So thank you very much for coming on. Thanks everybody. Stay safe out there. Bye bye.