 Good morning, good afternoon, good evening. Wherever you're hailing from, welcome to another episode of the Level Up Hour here on OpenShift TV. I am Chris Short, Executive Producer of OpenShift TV. I'm joined by the one and only, the illustrious Langdon White this morning for the show with the most, Langdon White and the Level Up Hour. So- And the most internet points. The most internet points for sure, by far. Right. How you doing, buddy? You doing all right? Not too bad, not too bad. I'm definitely under caffeinated today. As am I, I've been up since 3.30. Oh! I don't know why. I could not go back to sleep to save my life. And finally, like 4.45, I just gave it up and said goodbye. Right, that's very early. And I'm waiting for Red Hat's SSO to let me into the slides, so that's fine. Oh, well, that sounds good. So yeah, as I was mentioning before the show, I was struggling to figure out how to actually connect to the show this morning. You take one week off. Right, exactly. Everything goes... What happens? Everything goes all in a handbath. Sideways. Whatever you want to call it. Sideways, yeah, there you go. I realized I also have a typo, which I wanted to fix really quick. You know we can't fail on the show ever. Exactly. We cannot have any mistakes. No mistakes. No mistakes. So yeah, that's kind of the topic of the show this morning, right? Right, right. We kind of, basically the last stream that we did two weeks ago was, if you watch American football, was the equivalent of watching both football teams fumble the football all the way down the field. Or in soccer, it would be like goal kick, goal kick, goal kick, goal kick, for real football. It was just like, okay, how else could this fail? So today we hope to spruce this up, right? Exactly, exactly. So first and foremost, Mea Coppa, we had a scheduling snafu. So we were supposed to be doing Podman V3 today, but our special guest stars couldn't make it today at kind of at the last minute. So we had a reschedule. So you should have seen it on the Twitters that it changed around a little bit. However, yeah, or the calendar. But we will be having them next time. So we will, we are still planning on doing that episode. We just weren't able to do it today, sadly. Rescreen bot is being extra spammy this morning. Yeah. I saw a lot of chat. So, all right. So as we usually do, let us start with the slides. Assuming I can click all the right buttons to make that occur. That's a big assumption. Exactly. Look at that. Oh my gosh, I'm so proud of you. And ultimately also, oh, but I forgot to take my little notes of nice little links. So let me grab those, which will take just a second. They are not familiar. If you wanna talk through it, you can, go ahead. No, go ahead. If you're not familiar, you know, every show we have a topic, but you're more than welcome to ask any kind of question related to containers, you know, being a, you know, former CIS admin, now working in OpenShift and Kubernetes land, you know, I understand that that transition is not exactly smooth sometimes, right? Like containers are kind of hard to conceptualize at first. And then orchestrating them is even more difficult at times. So we tried to provide you with the capabilities to do just that, to level up your adoption of containers and embrace cloud native technologies of the future. Yes. And I will say, like my big thing is, and a little bit more than that, in that hopefully to convince you why containers will make your life better. It's not just another technology you have to learn and get under your belt, because that's the way the industry is moving, which is true, but also that they're super handy and that hopefully you will find that to be a positive experience. So level up our, and so I have my handy links, which theoretically we will share in the chat in a second. But right now, we will say, we are on the Twitter's, I'm Langdon with a one and Chris is Chris Short. Two S's. With two S's, yes, he's Chris Short, maybe. No, it's Chris Short, it's just, there happen to be two S's right there. I think it's funny how people kind of get these like, it's not a mantra, but like it's a word like mantra that I'm looking for, but like you get these like flows to how you say to spell your name and stuff. Like a friend of mine always said, his name is two P's, two I's, two T's, but he says it's super fast, right? So it's barely understandable by the time it comes out of his mouth. I would say like two S's like Mississippi, but Mississippi actually has two sets of S's. Right, that would be extra confusing, right? Like, yeah, yeah. Extra sinister, maybe? Extra AB, yes. Next time I ever walk into a coffee shop, I will say my name is Chris Short, two S's like Mississippi and see what they come up with. Exactly, you know, it'll have little to do with English or anything like that. But you can also join us on our Discord and that I think has already landed in the restream or in the chat. So join us there. There's often discussions, you know, don't limit yourself to any particular channel. If you feel free to say stuff, you know, the live stream channel obviously is live streaming. So if you say stuff there, it will show up everywhere else. So, but as I usually do, I also talk about the show notes. And so last episode was 27. And so we have some brief show notes there with a little bit of how to learn more about things, which you might find handy. And this is Dev Sandbox take two. So hopefully we will have a slightly better time with the Dev Sandbox. One kind of random note, if you remember way back around episode like two, and then for a few episodes, we talked about doing command line rendering for Blender using a container. One of my colleagues is actually, who's actually sometimes on the show Christian is unhappy with exactly how it works. So he's making some changes hopefully to improve it. So if you are interested in, you know, or if you're using that or use Blender or whatever you might want to take a look, we are, I will take a look at his pull requests imminently and then we can, you can see the merge assuming it's a good one. So yeah, so if you like that sort of thing, let us know. And just for everybody here, there's the link to the show notes. And yeah, let's move on from there. No more slides. No more slides. Exactly, exactly. Later, later. Now we are going to, okay, so we did a fair amount of the intro last time. So I'm not going to do too much of that this time. Right. We have this thing called the developer sandbox now. We have this thing called the developer sandbox. Really awesome. When you can figure out how to use it. Yeah, it's, you know, it is in beta. So it's kind of, you know, limited right now. I know the length has been extended from 14 to 30 days, how long this cluster will be alive. Right. But, and I think like, I was watching something, I don't know if it was one of our videos or if it was last show or what, but like, like any given unit is 30 days in the sense that you can go get another 30 days anytime you want. It's just that, you know, if you're trying to run that Bitcoin mining operation, you're going to have to restart it after 30 days. Yeah. I don't think these are good processors for Bitcoin mining. Probably not. Probably not. But basically, you know, putting a quasi, personally, I think putting a quasi arbitrary limit on it is just primarily going after bad actors. Not, you know, it's the intent is not to tell you that you shouldn't use it longer than 30 days. And specifically, the reason I'm commenting on this is because in whatever it was that I was watching, somebody commented, is that enough time to learn, you know, did you open shift or code ready workspaces or whatever? I don't know, maybe. But if it's not, you can certainly do it longer. You just need to re-add your stuff. And if you don't have other copies of your stuff when using this kind of demo where I, you know, it's probably a bad idea anyway. So basically, save all your yamls, right? Back up everything as you can, and you can apply them on the new cluster. Rural, you got a lot of that last pass, that sucks. Yes. So I'm going to stop sharing for one second and fix that. Not that that one actually I have memorized, but it will be a lot faster and more efficient if we can log in correctly. So let me actually just log in. So what I'm doing right now and one thing to note, you know, so you need to go sign up for developer subscription. It is free aside from, you know, some T's and C's. You can go and create your own account or you can use the various socials to do your logging in with. And then you can, sorry, just looking for the window to share. Then you can get this set up. And apparently this link is not good. So we will use this one anyway, but at least I'm logged in now, right? There you go. So do-to-do thing they're looking up for you, Langdon. Exactly. Yeah. All right, so a few things that I learned since last time, as well as, you know, kind of doing some experimentation and some more thoughts or whatever. Let's discuss this. So first and foremost, actually let me close these so that it's less likely to be angry with me. I tend to have a lot of windows open. I don't know if you've noticed. I notice, like me, I can't see my desktop, like the wallpaper. Right, right. I can't see it. Yeah, right. Actually, just a little sliver right here, I can see, never mind. One thing Noam did a few years ago, which was basically take the ability of putting, you know, like icons on your desktop, like putting, you know, saves or whatever. You can still turn it off, like you can still do it. But it has made me a much cleaner person. I will say, you know, as far as, Yeah, a little bit more organized, better, more likely to take notes. All right, so back to Dev Sandbox. So you get into Dev Sandbox by going to developers.readout.com, you sign up for an account, then you click the big button that says Developer Sandbox and it launches this site. If you're lucky, the SSO will be SSOE and you will just get logged in. If not, you will have to log in again. One thing I actually kind of glossed over is you will be presented two login boxes, one that says OpenShift SRE and one that says Dev Sandbox. Click the Dev Sandbox one, that is a known issue that they are working on fixing. So just, you know, ignore that other box for now. And speaking of SREs, I had a meeting with someone on the OpenShift dedicated team yesterday about an SRE show. Oh. To the channel. So that is in the works, no promises, no future stuff, but it's in the works and we're probably gonna have some SREs on the channel talking about not just OpenShift, of course, but how and why they built SREs the way they did, yeah. Yeah, I will say it's really, it's an interesting phenomenon. Like if you haven't read the book that kind of started it all from, some people at Google called Site Reliability Engineering. It's a quick read, take a look. Also, the Phoenix Project about DevOps, you know, if you kind of read both of those, I think you get a really interesting sense of the change in the philosophy of how software was delivered. But the thing to remember with that book is you are not Google. Just always remember. Right, right, right. You don't need to scale a database globally. Right, right. In real time, like they have, right? Like they have Spanner, right? You don't necessarily need to do that, right? Yeah, like that's not you. Yeah, I mean, as quasi or I don't know if it's actually insulting, but it seems like it should be, I mean, unicorns are unicorns, right? So they refer to Google and Facebook and a bunch of those other companies as unicorns a lot. I don't, you know, there's probably some underhanded nastiness to that, but really, you know, the core of it is true, which is that they are really unique, but that doesn't mean we can't learn from them. You know, and so yeah, so yeah, as you say, remember you're not Google, but the real point I was trying to get to there, even though I'm kind of long-winded sometimes, is I'm shocked by the amount of interest amongst, because I teach a course over at a university, the amount of interest among the students about growing up to be an SRE, which I think is really interesting, you know, and so actually one of my classes, I'm gonna have a guest lecture come in to talk about what it means to be an SRE. So I think that might be cool. Yeah. Okay, so back to Dev Sandbox, it's a developer sandbox. So first and foremost, I was very confused by, okay, so when you work with OpenShift, there's this concept of projects, alternately called namespaces, where basically that's kind of where all your code lives for a given, the word is so hard these days, but so let's say given application, even though an application may be made up of a number of applications. So when we talk about like the cool store, for example, it's actually made up of a bunch of different services, right, it has a web front end, it has a catalog component, it has an inventory component, all those things combine to build an application. So as a way to corral those things into one thing, we have this concept of a namespace or a project, those being synonymous. When Dev Sandbox sets up, we have access to three different projects, and we can't create more, so these are the three we get. And the idea of the setup is first and foremost, that Langdon code one that you will have, it will be your username dash code, that's actually not, I mean, you could use it, but it's not meant to be used. And that's why, I don't know if you remember from the last episode, but I was surprised because when I came into it, I landed in Langdon Dev, because I've worked with some organizations where they called the unit test level deployment code. And so I assumed that it was essentially unit test level deployment, but it's not. That's where some of your kind of infrastructure stuff lives, specifically where the backing store is essentially for your code ready workspace lands. So long story short, the thing called dash code, you should just ignore. Oh really? Yeah, just forget about it altogether. And in fact, if I set up the code ready workspace, I don't think any of them are running. You should see, you'll see it land. So I just started my code ready workspace and look at that. It's coming up as a thing right in Langdon code in that project. And it's not something I'm on a mess with unless I get really excited about how workspace works and want to go take a round in it for some reason. So is this like the default location where CRW is deployed every time, no matter what kind of deal? Yes, okay. Yeah, or at least as far as I can tell. You know, I don't have that confirmed from the. Yeah, we probably should get somebody to talk about this more in depth maybe. Right. If you continue to struggle, yeah. Yeah, I think, I don't know if it's for this show, but I think for a show, it might be interesting to talk about how workspaces works as an application on OpenShift. And to be clear, right? There's no particular affinity for your workspace back end or whatever to live in something called dash code. It's just, this is how Dev Sandbox was set up. And part of why I got confused is because other setups I've seen, it's been in other projects. If you're right. And like, I think I even mislead you myself because I was like, I wonder if code is like where you're supposed to just do stuff. That's, I thought it was a very reasonable assumption, right? So I thought that was too. So yeah. So first and foremost, ignore this thing that I have just spent so much time talking about. So your stuff should go in dash Dev. And this is where we get into kind of more traditional deployment, you know, stories or whatever where Dev is kind of where you play around with stuff. And then whatever we call it here, stage, stage is where, you know, you stage it, right? And, you know, because it's beta, because it's a demo, all that stuff, you know, I don't think anybody on the works, on the, sorry, on the Dev Sandbox team wanted to call anything prod, right? Yeah, like we don't want you running production stuff in these instances. Exactly. Like this is for you to learn, train, you know, figure it out, break safely, you know. Right, right. But, you know, you know, that said, the thing that you should be expecting to surface if you want to collaborate with somebody else, you know, and check the UI of something or whatever, the idea here is stage. And the reason we have at least two is because one of the things that you should be or might want to be experimenting with is the transition from one project to another or one, even, you know, obviously not in this scenario, but, you know, one of the things you want to be thinking about is how you're transitioning your applications from one environment to another environment, be it on the same cluster, on different clusters, et cetera. So that's why, or at least, you know, that's why these two different projects are included. Not so much the idea being that you would be running multiple, and again, I struggle with the word application. So, you know, you don't want to be, it would be surprising for you to run, you know, the cool store and, you know, your, what's the most popular software these days, it's like to-do system, you know, like the idea with OpenShift, with Dev Sandbox, right, is that you're going to work on kind of one application here, even if it's made up of 37 different services. So it's kind of set up for that kind of scenario. Doesn't mean you can't do something else, I'm just saying that that's like the philosophy behind it, as I've often said on the show, if you understand the philosophy behind software, it makes it much easier, in my experience, makes it much easier to grok, you know, your choices or guess what to do next. So, again, relatively long-winded way of saying, these are what these projects are for, and so, you know, play around with it, knowing that and things will go better for you. All right, so moving on from there, what I first wanted to show here, or next wanted to show, I'm going to actually go and do this in stage because I don't have anything there. As I just got done saying, this is probably not the right way to do it, but, you know, if I were to do the show, I'm going to go delete stuff later, right? So you're presented with this from the get-go. If you really are just wanting to try stuff out and you want to just play around a little bit, you know, pick your favorite language, do a sample, and you will get your application deployed. I strongly recommend, and we've talked about, I think we've talked about this on the show, there it is, you know, go watch the logs, go see what's actually happening. Go figure out what's going on behind the scenes there. Right, right. It definitely helps you get your head wrapped around, you know, later on why things are breaking. You know, if you remember from a few shows ago, I was really struggling, I think before the show, I think I figured it out before we actually did the show, with why my container wasn't working properly, and it turned out that the error was way at the beginning of the logs and that it couldn't get the base container that I was looking for. And so, because all of my Docker file after that assumed the one I had, everything was broken, but I was only getting a warning about the fact that I couldn't get to the container I actually wanted. So this is engaging with the Red Hat catalog, you have to have a secret if you want something that's privileged. So check out those logs, you know, get an idea of what's actually happening, you know, so there's a bunch of, you know, stuff about the setup and the Python thing. We're not really gonna go through it too deeply today, but as you can see, you know, we get this nice sample, it has come up. This is, I think one of the coolest things in software is that I can just click that little button and I will get two of them. Like, I know I'm easily amused but it's still amazing. I know, I am easily amused as well and I have to say that like my first experience with OpenShift 4, like out in the field, I was like, oh man, I really like this. And I believe this was in OpenShift 3 as well and it was just... Yeah, yeah, it's been around for a while. Click, click, click. Oh, there's four more. Okay, fine, thanks. Right, and if you are messing with the serverless stuff, watching it go automatically to zero when you don't use it is also super cool. You know... There's nothing in this workspace. Well, that's because there's nothing to do. Right, right. And actually the serverless stuff is where you really see why corkis is kind of amazing because wait, do I have... I don't have a corkis project up and running but maybe we'll get to that. Hold on, we'll get to it. Table it. Yeah, one thing at a time. All right, so, okay, so in order to access like an application inside of OpenShift, you need some sort of what, you know, the fancy term is some sort of ingress. Into OpenShift and in order to get that, what we create is called a route. Now, when I created that sample application, it included a bunch of nice things, right? It included the obvious code bits, which is what this build part is, right? You know, with the Python app, you need, you know, the Python code but it also included this thing called a service and this thing called a route. And so the service, this is one of the things that I most appreciate actually about Kubernetes and OpenShift is that by, almost by default, the expectation is that you put a layer of indirection between your application and the URL you use to get to it. Why is this so important? Because applications change and when applications change, you wanna do things like, you know, have some of your, sorry, some of your visitors continuing to hit your old one while you deploy your new one and new visitors start hitting the new one, things like that. So there are lots and lots of scenarios where having that layer of indirection between the URL and the actual application is a lifesaver. And so the default coming up with that layer of indirection, even though to a lot of people, I think the reason they shy away from it is they feel like it's over-engineering. And this is one of those places where I, while I tend to over-engineer, I strongly recommend kind of that layer of indirection. So when you're setting up your own application, consider putting in a service even though it's not required. Right, like it's not required, but it's always great to have. Exactly. So here is our fancy fancy, apparently Django application on OpenShift. If you're unfamiliar with Django, it's basically a content management system, open source written in Python, kind of does all the things that CMS does. So if you want to run your heavyweight blog, think about Django. If you want a lighter weight one, excuse me, something like Flask might be a better choice. Now I lost one window. It'll work for anybody, right? Like no judgment here. Yeah, yeah, yeah. For you to run with it, right? I'm a little judgy of Django. Well, I'm not. Yeah, there you go, there you go. Okay, so that's my little Python sample application. I am actually just gonna delete it. And one of the things, this is something that I'm trying to figure out how to file a bug about this because I'm not sure what exactly I'm trying to say, but when I click this delete here, I expect to immediately be able to go and create the thing again. And you can't a lot of the time. So when I delete it, what I want to do is then, okay, so it's deleting, it's doing its little cooking. I go and look at the project and notice a couple of things. For example, hey, look, my service is still there. So arguably my service is still there and so now I could put some other thing behind it. I could keep that old route, because I think the route was there too. I could keep the old route and the service and put something else behind that. So there's a really strong positive argument for being able to do that. The thing is, if I go into the topology view and right click delete, my expectation, I think, is that all of that stuff is blown away and that I could immediately recreate it. So I wonder if almost we need another option in the menu that is something like really, really destroy it versus mostly destroy it. So in order to get this back to square one, so that I can redeploy that same Python sample app, I need to actually manually remove both the route, the sample, and then I think an image stream. And what particularly annoys me about image streams is that you have to go to the administrator view and then go to builds and then image streams and then delete it here. So there's, like I said, there's a few different ways this could be handled. So I'm not convinced I know the right one, but that experience right is like, I want an expectation that if there should be a button, I think in the topology view that says completely destroy this. The other way you could do this is that the Python sample or any application could do the general Kubernetes thing of being relatively idempotent. And so the other option would be that it shouldn't fail when the things it's trying to create already exist. So normally how you would blow all of it away is delete the namespace or the project, right? Right, that's how I would do it. But you can do that here, so. Right, that actually won't kill the image build though. It won't? Or the image stream. Oh, no, it won't because that's hot. Yeah, kind of outside. So yeah, yeah. So I often will also delete the workspace and my suspicion is that the engineers who work on this stuff for the most part do the same thing. But like in the Dev Sandbox scenario, or I imagine in most like enterprise production scenarios, I probably can't delete the namespace at all, right? Because if you have a namespace, it's like your namespace and you have to go get another one and there's some process behind that. Right, right, exactly. It's not something I can casually just wipe out, right? Depends on the permissions in your environment, but yeah. Exactly, exactly. But at least if I was a junior developer at an organization, it's not something I would risk. I wouldn't even ask the question. I would just assume that the little box that I was allowed to live in is the box I'm allowed to live in and I'm not gonna go burning down the box, right? It's kind of like if I get a virtual machine in my enterprise or whatever as a junior developer, I'm not gonna ever delete the virtual machine, right? I'm gonna keep using it. I'm gonna keep trying to fix whatever's wrong with it. I don't know, maybe I'm crazy. Okay, so going back a little bit. So I flipped back over to the dev one just because I put a couple of projects in here. So for a few episodes, we talked about the cool store. We wanna talk about it more. And so these are two parts of the cool store. Let me rearrange some windows so I can show you basically, so I can show you this desktop, but there's a lot of junk up here. So many windows. All right, I don't know where the proliferation comes from. It's called work. Exactly. All right, hopefully... Yeah, okay. Let's stop that sharing and start this sharing. Did that freeze or something? What happened there? No, I just wanna have two windows at the same time. And I wasn't sure exactly how I was gonna talk about it, so I didn't prepare for it. That is very tiny, so... Yeah, okay, sorry. How did I... I had it set so that it was bigger and I had it nicely bigger. Oh, really? Yeah, just so I remember how I did it before. Global settings? Yeah, it was something like global... Text size or font size, I think. That didn't seem to make any difference whatsoever. Save or... I think I did. Like, I think it's immediate cloud. So the right side is fine. I think the left side is... They actually use the control plus-plus interface. Yeah, it's like a different font setting. I don't know, how's that? You don't really need to see this part that much anyway. Yeah, don't worry about the left-hand side, too, folks. The right-hand side, we want you to see. Right, right, so... All right, so what I wanna show here is... Okay, so I know it's cut off because of poor naming on my part, but so I was... Because I was experimenting, I gave it the brilliant name of EXP for Experimental Catalog Go. And so that's this directory here, this Experimental. And so this is a Go application that... Oh, I do have a Quarkus app, so I can show you how fast it is. So if I can click on the thing. So what I wanna show here is... So this is in a public repo. It's just under my normal namespace. I didn't put it under the level of power because the content is not interesting per se. I may move it and add it into the actual level of power stuff, but it's just kind of like meh. But so the reason it has to be public though is... So I'll just show you... Actually, why don't we just do it? Yeah, do that. So what I can do is I'll delete this Yahoo and go over here. Deployment config is gone. Deployment config is gone and then I gotta kill the image stream. Make sure I get the right one. Don't kill the wrong one. And then I said I usually just check the project itself to make sure I hit everything. And I did because the deployment config, that's why I prefer to use deployment configs because it should kind of take down everything when I take the one piece away. So what I do here is I do an ad, but I'm gonna do an ad from Git. And of course, I don't remember the user or the URL. I didn't log in. How is that possible? This is my level of our browser. And so I'm gonna get an HTTPS URL. I've had bad luck with the SSH URLs, so just keep that in mind. Oh, yeah, you're not gonna be able to use the SSH URL because you don't have keys in that pairing setup. Right, right. One of the things... This is another thing, though, I kind of feel like I should go file a bug for. Like, you can easily convert the SSH URL into an HTTP URL. So it'd be nice if I dropped the SSH one. It would say something like, you know, mostly validated, but I changed it to an HTTPS URL that looks like this. You know, that would be nice. That would be cool. I should tell Serena from the future that. Well, that's... Yeah, that's what I was gonna say. That's what I was gonna file a bug. Oops, wrong button altogether. Just don't disconnect. I was gonna show... Yeah, exactly. That would be awkward. Chris is gonna pull up his thing and try to do something. Well, I'm gonna reconnect. Yeah. If I do... I think it's... Yeah, here. So, yeah, one thing I just noticed, I was trying to find the, like, you know, machine size, like the whole compute sidebar thing in the sandbox is not there. So that's interesting. Really? Yeah, on the administration side. I mean, it's not germane to the discussion. I just realized this all... Yeah, no, I'm curious though now. I thought, oh, you have quotas. Oh, well, I have no quotas, apparently. Yeah, it is kind of not there. Yeah. So this is what it's like to work as a real user and not always have close to that. No, I'm scared. Okay, so the point I was trying to make with... What is this catalog? Was the big reason is because if I do... Oh, my God, Mike. What's the... Let's see. Export PS1 equals... Let's just do dollar. Oops. Let's kill... I'm just trying to... I was just going to kill PowerLine because it's... I don't know why it's so long. Open in like a bash prompt or something. Like a... Or if you have the opposite, right? Like ZSH versus Bash kind of thing. Oh, yeah, I could try that. Nope. Oh, it works in ZSH too. It's not found. I mean, I could do SH. It doesn't... I don't know if it's going to help. Let's see. Well, SH, I think, still reads the bash RCA file and everything. It does? That's weird. In your user environment, yeah. And like home, yeah. All right, let me just... I'm actually just going to disable PowerLine. Okay, that works too. But my typing is prone to failure, as we all know. Just slightly. Yes. All right, so theoretically, this one will be a little better. Are you sure? There we go. There we go. Okay, so the reason I was commenting on it primarily is because if I do remote-v, I would like to be able to just drop this in there, right? I don't... And it's easily translatable from that to be an HTTPS URL because then I don't have to go open up a web browser and go find out what the HTTPS URL is because I have no idea. Maybe there's a way and get that you can actually tell it to give me the other URL, but that's why I think it'd be kind of nice if you could just drop an SC20 in there. All right, so continuing on. Okay, so it's smartly detected that this is a Go project. It said, okay, I'm going to plop that on top of this version of Go. I have some other options, but I'm going to take the one it guessed. It decided to create it as a... Oh, I didn't know this was there. This was. Today we learned. Today we learned. Let's do Cool Store. And then I'm going to do deployment config just to make my life easier later. And then we're going to say, yes, create a route, please. Oh, see, this is why I get annoyed. So, yeah, I forgot about secrets is also sometimes they're trying to think about where it is. So in the secrets, there is a webhook for the Go app. There's actually two. Hopefully I didn't delete the wrong one. You know, things go poorly. So that should work now. Oh, that's I was wondering. I thought it would yell at me earlier. Oops, click. Oh, yeah. So because, yeah, this is another thing I should go file a bug about. Sometimes, even though I hit the create and it failed, it actually started. Yeah, it's just like a timeout, I think. Well, and so now I have created something like a build config, even though I didn't successfully do the create. So to try to do the create again, I have to go delete the build config. It's very weird. So I need to go like I need to go experiment with this carefully because I could be completely crazy, which is certainly possible. But I have experienced that if I hit create and the create fails, sometimes it did create some parts of it. And so if I try to do the create again, it will fail because part of it already exists. I can see by the look on your face, you think I'm crazy. No, I'm actually typing in chat. I'm sorry. Oh, yeah, no worries. So you can also think I'm crazy. When it comes to these dev sandboxes, right, since they are in beta right now, I'm not like I need to put this lightly because I don't want to insult anybody, right? Like I'm not expecting full perfectionality and perfection right now, right? Like I'm hoping for pods to come up, deployments to work, those basic core Kubernetes services or components, I should say, because service is a component in Kubernetes. Those core components all work, right? So right now, I'm not surprised. Right, right. When we ship this thing without the beta label, that would surprise me, right? Like, mm-hmm, mm-hmm. So in their end of, I had forgotten that I actually do have fish installed. I didn't have ZSH. I did have fish, so I could have used fish. My, I was trying, I actually have one of my computers is actually using fish exclusively now. It's a great shell. But my bashisms are so ingrained. Oh yeah. It's hard to use. You know, like just, just my like, you know, just my aliases file, like it's just, you know. And I found actually a cool script that will convert your bash aliases to fish functions, fish commands, I can't remember what it's called, and put them in the right place because they go in this like config directory and stuff. And so most of them work, but there are some of them that I need to go figure out how they work. But yeah, so I've been slowly trying it out. I just haven't had, you know, it's just, it's only been a couple of months. So I have it on one computer so that it doesn't like destroy my productivity all the rest of the time while I kind of learn it. Carlos, sadly, it does not support serverless. I'm personally deeply offended. I do know that both service mesh and serverless are very high on the list for things that should land or that we want to land really soon. That said, though, if you go to learn.openshift, right, that's the one with all the demos, you can go and experiment with serverless in there directly because those like the setups for those workshops are set up to use serverless, et cetera. So you can play with it. OK, we were talking a bit. Logs ran by. You know, it built out some stuff. Let's go see how it did poorly, apparently. Wow, bad. Was it saying little check fail? OK, so this is where I was struggling with the Dev Sandbox kind of setup versus OpenShift setup. So the problem here is that this application is set up to be pushed into OpenShift, not kind of read by OpenShift. And this is a thing that we would like to or like I would like to kind of see how to fix it. I'm not sure if the problem is in the code base for the catalog go here or if the problem is kind of like how OpenShift approaches it. It's not you? It could very well be me. But I don't think it's me. So what I can show you is if you go back to and this is why I was messing around with with the works with workspaces. I cannot talk. So I think I need to. Oops, I need to delete this. You can only have two workspaces. But I'm not sure if it's to total or to running. So I'm just going to let's see. So I can say I'll go workspace. Yeah, so you can only have two workspaces on this setup. So I can kill this one. And then I'm afraid this is actually going to inject code. Yeah, so I need to stop this one. So you have to you have to have two or less total and then you can run one at a time. And it's pretty easy to kind of go back and forth. It's just I'm still getting used to what the numbers are. I don't know. Did we have good comments in the chat while we're waiting for this to load? Wanting to onboard people with serverless right out of the box. Oh, yeah. I'm totally down with that. Yeah, like I am too. It's just not there yet. Yeah, like we're working on it. Does the sandbox allow installed operators that can be installed on the space of scope? Nope, not there yet. Yeah, so basically available to you and the interface. The fundamental flaw is operators are not available. And so the operator hub is not available within OpenShift. Right. Well, let's say user installed operators. Yeah, kind of in any way because the challenge right now is that for at least this is my understanding is that to get kind of a user scoped operator is not something OpenShift does very well at this point. You have to have them at the kind of cluster level. So in order for OpenShift, like the dev sandbox to be able to offer an operator, it needs to be able to install at the user level rather than at the cluster admin level. And so that's what's in progress. But it's a problem like it's not just a problem for dev sandbox. So it's very high on the priority list. Like this is something we really want to see. Hopefully that helps. So yeah, so it's not that the like it's not that hub isn't available per se. It's just you don't have privileges to install operators. That said, you can go and get any other kind of container you want to get. You just can't use an operator because the privileges it requires are too high for a regular user. Does that make sense? Yeah. All right. And yeah, to your point, right, there are operators installed. There's nothing wrong with us having operators. It's just that you can't install them as a user or can't choose to consume them as a user. In fact, I don't want to put words in the dedicated team's mouth, but this is almost like OpenShift running in OpenShift, right? So there is a nested layer here that you're not going to see. There's some abstraction being taken away because this is a Dev Sandbox. Right. So. But there's other scenarios where this operators by users in a sense is also a problem like something else that people want fixed. So like I said, at least for me, right, if I was looking at Red Hat and I said, oh, Dev Sandbox has this problem, what's the priority of that, right? Right. What I'm just trying to elaborate on is that Dev Sandbox is just one instance of this problem. It is a problem for a number of other scenarios as well. And so as a result, it's a pretty high priority, specifically with actually service mesh and serverless. So you may even see a solution where service mesh and serverless just become available to developers in Dev Sandbox without you mucking with the operator in a sense, it'll just kind of be set up. Okay, moving on. So I went and did the go like sample in code ready workspaces. And as you can see, I have like a go application here, right? The thing is, is that it's just like a go application. So that's actually not really what I wanted, right? What I really wanted was a way to say, give me kind of a go framework so that I can go and put my own code there. So this isn't quite what we want, but I would like to point out how the similarity, if you haven't used code ready workspaces, the similarity between this, which is Visual Studio Code and this, which is code ready workspaces, which is based on Che. The two projects, VS Code and Che, share a ton of code, which is super cool, I think, that we have this like open source community that's kind of going two different directions, but with the same code base. Che and code ready workspaces are looking for an online IDE and Visual Studio is looking for an offline IDE. One of the super neat features in code ready workspaces, which I don't know of a way to do in Visual Studio might exist, is this thing called a dev file, which if you've ever worked, especially as a team lead for a software development team, it is incredibly difficult. I find this video very distracting, sorry. It's incredibly difficult to onboard new people onto an existing software project that's been going on for a long time. And one of the reasons, obviously there's all the teaching and stuff about how you do things, but there's also the reason of I want to make sure they have the exact right operating system, the exact rate code base, exact rate patch level, et cetera, et cetera, so that we're all operating from the same exact position. Whether we decide to continuously integrate patches or we decide to delay them for a patch day or whatever, what I want is my whole team to be operating from the same position at any given point. So Vagrant, if you've ever used Vagrant, tried to solve this or it does solve this to some extent, for many years now using virtual machines, basically you have this thing called a Vagrant file, I give it to everyone on my team, they click Vagrant up and bang, they have an environment that looks like everybody else is on the team. Code ready workspaces with this dev file thing, which let's see if I can find it. Actually I know it's easily accessible here. Nope, wrong button. It's easily accessible here. This dev file thing, I can give somebody else this dev file and it will create exactly the same development environment. And on top of that, if you're using something like code ready workspaces, which is being deployed on an open shift, you know exactly what it looks like because it's all coming from the same open shift, it's all coming from the same operator, which is then in turn creating the exact same development environment. So yeah, a Vagrant VM and open shift, but we should totally do that for a show. Oh my gosh, that would be so funny. We would have to have Andrew on to make sure that I didn't script C and V too badly. Well, no, you wouldn't be interfacing with C and V, right? Like you would just run Vagrant in a pod at that point. Right? But where's the VM go? In that same pod. I don't think it's gonna be lightweight or anything. No, see I was imagining, so one of the things Vagrant can do is you can actually say, give me an EC2 machine rather than a local machine. So I was imagining doing, there might be an open shift plugin where I can say, give me a VM inside open shift. I've actually, if you like open shift, sorry, if you like Vagrant, I have experimented a bunch with their container tooling. So you can actually say, instead of a Vagrant VM, you can have a Vagrant container. And many years ago, if you've ever seen the container development kit, the original version of that actually works in Vagrant. So it's entirely in Vagrant. And if you use Vagrant all the time and you use it with rel all the time, I also wrote a plugin for Vagrant that does your Red Hat registration for rel automatically. Which may be interesting to people who use Vagrant and rel quite a lot. And I have since discontinued my support for it, but it was popular enough in the community that it has now grown its own owners who now maintain and do a good job. So little sidebar, go check out Vagrant. We should totally do a Vagrant VM inside of OpenShift one of these days. Okay, so back to Dev Sandbox and CodeReady Workspaces. So the experience here is really, really good for I didn't actually want to experiment with OpenShift. I wanted an online IDE, which I could experiment with this online IDE. So that's cool, but not quite what I was looking for. What we were looking for was I want an online IDE for the things I'm using in OpenShift, if that makes sense. So I'm actually going to go back here and destroy this because it's not what I want. But the reason I bring it up is like, if that's your goal, it's a good one and you have to do it kind of differently. So what instead I want to do is a custom workspace. Now, I'm trying to remember how you do this. I'm going to say, give me a generic go Dev file. Excuse me, a generic go Dev file. And I can create and open that and then give it a second. Now I'm confused about who's brother is vagrant. Yeah, I don't know. Is their logo still like a vagrant? Yeah, yeah, I know they went all corporate a few years ago. So, you know, yeah, I mean, I remember using it when it was primarily targeted as as for like web developers on Mac, which was how I started using it, not on Mac or as a web developer, but that was when I started using it. I just found it super handy to be able to pre describe. It was basically config management for developers, right? Is that like, well, it was like, yeah, like consistent environment every single time, kind of, right? Right. And pre and elsewhere. Yeah, exactly. And so you couldn't do it for everything. Yeah. Yeah. And I didn't want to go figure it out. Puppet to create my development environment. OK, so now we have a code base that, you know, is is a little more basic and then, you know, basically what I can do is I can now add my files to this workspace by trying to remember how to do it. Oh, wait a minute. It gave me the whole sample again. And I want the whole sample again. I swear I made this work before. So what I really what I really want is I want an IDE workspace based on my Git repo, right? And I'm not sure that I figured out exactly how to do that. And so this is something that, you know, maybe we cover again when we're when we're doing vagrant VMs and OpenShift, you know, and kind of come back to once I go and try to figure this out because like, at least for me, like, I really like code ready workspaces and I like OpenShift, but my goal with Dev Sandbox is actually to be using them more together. And what I haven't found a good way of doing is saying, OK, I made this project over here from a Git repo. Give me the code ready workspace based on that, you know, component, right? So I can kind of go through eventually and do it manually. But like, I feel like I must be missing something about how to do this more dynamically, you know, where I can kind of, you know, right click and say go and things will happen. So hopefully that's a little bit of an introduction. I was going to, I was kind of thinking about stopping there. Maybe loading the, yeah, do the points. Maybe see what the corkis one looks like. Oh, one thing I wanted to see if I could do quickly, but I think it's all broken is, yeah. So the thing that's really cool about corkis is it's a Java JVM, right? And it's based on grail or grail, however you want to say. Yeah, and a grail. But it's the thing that's crazy about it for anybody who's worked with Java is the JVM startup load time, you know, to get an application up and running is literally 10 to 15 milliseconds. Yeah. Which if you've done any Java stuff whatsoever is normally like a minute. And like Java in my experience, right? Like I did a bunch of Java work. It's really performant once it's going. But if you want to do something like serverless where you wanted to be able to scale to zero, you cannot scale it to zero. You have to keep at least one hot, right? And what corkis lets you do is have one that is zero and then still can respond to a request in a reasonable enough time frame, even though it's starting up the entire JVM. So somebody asks, is the same file for Odo and CRW? Yeah. So Odo, right. Odo is working on dev file stuff. There's a dev file v2 in the works as well. So I really like, I think dev file, that concept is amazing. And I really, I don't know anywhere near enough about it. Oh, so Narendra brings up that corkis is not a great way to learn Java. I could see that. Yeah. I mean, you know, but it's like, it's very portable. It's kind of like, it's like, I wouldn't want to learn C, C plus plus from the Facebook PHP compiler either. Right. Yeah. You know, like they have a compiler for PHP this, I think it's C or C plus plus. You know, like that's, it's really meant to be a post production, you know, kind of scenario. I think that corkis, though, like the corkis team wants to be a place to go and learn Java. So if you have feedback for them, you know, feel free to share it with us, share it with them, probably better off sharing it with them. And, you know, just talk about why, you know, why you might not find it to be particularly easy to understand. Okay. Points. Where is that window? I wonder. You probably closed it, I bet. Yeah, probably. I did not. In fact, good for you. Look at that. So you all should be able to see it. And we're going to stress it out a little bit. And so points. 4,600 for Nurendev. Very nice. Very nice. Netherlands hack them with 4,500. Then haven't seen a lot of movement from Noah friction and Joe fuzz the past couple of episodes. So we, I'm hoping that we'll, we'll see that movement. Detective Conan Kudo and bacon fork. Definitely up and coming. And let me throw the. Today's points into the chat. Thank you. Playing risky says speaking of image builds. I'm looking forward to the build pack. Yes. Yeah. Yeah. I know a lot of, I know a number of you are working on that. Yeah. I am too. I'm really curious how that's going to work. Exactly. I haven't really experimented with it at all. But it's something it's like on my list of things to do. It's just the list isn't like any kind of reasonable length. So yeah. Yeah. But. Current status of the points. Thank you all so much for coming along. We, we are. So close. So close. To giving out. You know, extrinsic rewards for the points rather than just intrinsic. We are, we are kind of waiting on legal at the moment. As you do. And. Yeah. So Kona Kudo who was masquerading as the eighth doctor is back to Kona Kudo. And thanks all for joining us. I think I wanted to kind of, I think wrap up there. Unless anybody else had any more questions. Give it like good sevens, eight seconds before we. Pull the plug. So everybody can actually hear what we just said. Yeah, right. Right. But, you know, like I said, I kind of wanted to give a little bit better overview of dev sandbox. I think some of my. Challenges in the last episode were related to these things that I think like. At least for me, it's a little bit unintuitive how some of these pieces connect together. And so, you know, hopefully this episode has helped you intuit it better so that you can have a more positive experience than we did the first time we took a swing at it. But it is super powerful. Like you can, you really can do a lot of stuff. You know, you can use tools like we mentioned in the chat. You can use tools like Odo. We have not done Odo on the show. We really should. You know, we've only done. The developer advocate hour. Oh, right. Okay. Yes. We've done on the channel. Not for a while. I don't think we've talked about it in months to be honest with you. So yeah, we've done it elsewhere on the channel, but yeah, we can bring it back here. Okay. The other thing I wanted to, oh, sorry. I meant to also do was. We have a couple of other shows. Shows a couple of other episodes that were about the dev sandbox. That I grabbed the video links for. That if anybody wanted to see some, you know, more accomplished people do things with dev sandbox. So the first one is a guy named Don shank. Who is a big dot net advocate within red hat. And has worked on a lot of dot net applications over the years. And he's talking about dev sandbox particularly. It's kind of like launch day talk, but at the same time he talks a lot about using dot net on, on the dev sandbox. So I think that's kind of neat. I would, I'm a big fantasy sharp have been for a long time. The other video is a dev nation talk about using dev sandbox and walking through. I want to say it's a Node.js app, but now I can't remember. I might be, I might be misremembering. So that's, it's definitely dev nation. It's definitely interesting. I just can't remember if it was Node.js or if it was some other language. But yeah, who knows who knows exactly. Yeah. All right. So everyone had a chance to get their questions. And I think you just mentioned coming up next on the channel is the wonderful ask an admin or ask an open shift admin show. We're going to be talking about DNS and cluster network game. It's going to be super, super fun. You know, you'll have used some DNS. And remember pod man v3. We'll be talking about that next week on this show. And then with any luck, if I can make the, if I can make the timing work, I'm going to be help hosting the rail show in a few weeks. And we may, who knows, maybe there'll be some points given out then snap. Right. So you never could, you never know. So yeah, I just, I have a conflict that I'm trying to get out of basically at this point to try to be able to host the show. I mean, do you need me to step in? Well, it would be with Boston University. So I'm not sure it'd be a big help. But yeah, so I'm, I'm trying. So we'll see what happens. But thanks everybody for coming. And we will see you next time. Yeah. Take it easy everybody. Stay safe out there. Thanks.