Red Hat OpenShift Developer Experience Office Hours, 13 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Developer Exp Office Hours: A deep dive into CodeReady Workspaces w/ Angel Misevski & David Harris

Description

Join OpenShift's Developer Experience experts and occasional special guest for our regularly scheduled program filled with cloud native, Kubernetes, and OpenShift tips and tricks for developers.

A

Good morning, good afternoon, good evening, wherever you're hailing from welcome to another edition of the developer experience office hours here on openshift tv, I'm chris short, executive producer of openshift tv and I am joined by several friends from red hat here- uh we're going to be talking about uh code, ready, workspace is kind of in depth and I would like to hand it off to david first uh david. Please introduce yourself to the audience.

B

Hi folks, I'm david harris, so I'm the product manager for code ready workspaces. I also look after a bunch of other tooling that we have for the inner loop experience. So it's great to be here. Have any questions? Stick them in the chat be more than happy to answer them as we go.

A

Yeah awesome. Thank you.

C

Angel you want to go uh yeah. um My name is angel mizhevsky, I'm a senior software engineer, working on code, ready workspaces on uh eclipse, che and stuff like that. So I work on the stuff that we're gonna be talking about today, um based up here in toronto. um Oh cool and yeah, not much to that much more to add there.

C

I I have a very small window of focus, but it is on what we are demoing, unlike david, who touches many things.

A

Awesome, it's good to hear people from toronto on the stream, because being here in detroit makes me feel a little closer to the folks that I'm talking to awesome so code, ready, workspaces or ryan. Did you want to introduce yourself since you keep popping in and out I mean.

D

I'm gonna be around in the in the chat uh helping with questions and in case I pop up later. I just want to say hi at the top of the show here, um yeah say hello and chat uh folks and I'll I'll do my best to keep track of what the activity there.

A

Sounds good so crw. It's awesome tell me more.

B

I think you've said all there is. That needs to be said. We're done right.

A

All right and we're done here out, we go. Let me play the outro.

C

uh Yeah I mean I can talk about it a bit so uh code ready workspaces. Crw is basically a cloud ide where the idea is you're. Writing programs that you know you're running in a kubernetes cluster in an open shift cluster, that's a different modality than running something locally on your computer, and so it makes some sense to have a way of developing things in that cluster reusing the sort of concepts you're using to deploy.

C

You know multiple services, multiple backends, and putting that putting your development environment in the cluster to match sort of what you're dealing with in reality, rather than you know, having your local setup running a bunch of docker containers and trying to network them together. So it's basically a way to simplify that setup, put everything together in a real, easy way and it give you a familiar sort of environment but in a sort of different underlying system that it's running on yeah. I don't know if you want to add anything david.

B

That was good, I mean yeah. There's kind of two two key things to touch on, like one of the principles is that anyone with a browser can easily contribute code, so, instead of you needing the high spec machine, um just to be able to run simple mode like that, you can run everything in the clouds.

B

um It's really good for like open source projects, in particular, where we kind of see people dipping in and out of a lot of different runtime stacks, and instead of having to have everything on your machine to deal with all of those different environments, you can just quickly click a link provided to you by that open source project spins up a workspace and you've got everything that you need in your browser with some of red hat's, more enterprise security concerned customers.

B

This is also a way where you can not like enforce control, but you can kind of get that sense of.

B

What your development teams have access to and be able to provide them everything they need in a very auditable way and keep everything off very hard to secure laptops.

C

Yeah definitely- and you know what you're getting is uh the immutability of a docker container for your environment, so your dependencies are all set to you. You know you define what you need to build your application and everyone can immediately just grab it and start an ide in it. Basically, so that's the that's the pitch overall, I would say.

A

Just to let the audience know kind of uh I'm dealing with a slightly sick dog today. So if you see me doing this, it's me trying to calm her down and everything um but yeah. uh So if it brings a you know, unified experience to a group of developers, code ready, workspaces does and it allows you to not have to have these various bespoke environments in which you can code.

A

What does that enable for people in organizations.

C

It basically enables you to sort of get people started on board more quickly and also, you know, run into different situations and just kind of dive right into writing the code. Don't don't worry about setup? Don't worry about configuration, don't worry about here's the list of tools. You need to install to build this project. Here's the build process, we kind of encapsulate everything from you know. You can have multiple containers running so that when your workspace starts up, it also starts up.

C

Your database container starts up a front end container if you're working on the back end or a you know back end container if you're working on the front end. Basically it's a one-click way of defining what your deployment looks like um and then starting that up, so that you can kind of focus in on the part that you need, while keeping in mind that there are related components. You have to worry about. So you know my application interacts with the database.

C

Your onboarding doc is going to say here's you know deploy this database, here's the configuration for the database, uh then you start up your program locally when you're debugging it or whatever, because they connect to the database and there's a lot of hoops to potentially jump through to get that working right and there's some maintenance to keeping it running right. If you're, you know updating your system stuff like that, I pretty consistently run into.

C

Why is my build broken now that I've, you know, updated the fedora 34 or something like that, um so things like that are what we want to avoid, so encapsulating, basically, the components that run your workspace, the network, the components that run your application, the networking that sort of connects everything together and also the sort of build logic of you know. What's the sequence you have to do things in. Do you have to start this start this and wait for it to be ready before starting another component?

C

That sort of thing and yeah we'll talk about it more, I'm sure in a bit, but it's all encapsulated in a single file that you know you can just keep this yaml file that defines your entire development environment and just pass it into the program and get an identical environment. You know practically for for me. I work on the sort of eclipse j project which is the upstream to code, ready, workspaces and we've got a large number of repos all have different setups, some of them some of them.

C

I don't contribute too often, but when I do contribute, you need to install a bunch of you know: linters, a bunch of tooling that is specific to that project, um with sort of code ready workspaces. What I can do is just feed that project's dev file. That defines the workspace that you need for that. You know for the for the docs repo, for example, feed that into code ready, workspaces and instantly have everything set up that I need click, a few buttons to do the validations that are required and just more easily write the code.

A

Awesome, so if, if I were a new developer getting started in an organization that was using crw or I'm an admin, that's installing crw. I guess where do I kind of begin right like.

C

uh Yeah, so I mean crw uh there's a number of ways to install it. uh I think the sort of mainline way you'd want to do it is it's just an operator. uh You can go to operator hub and just grab it and deploy it, and it should be pretty straightforward once it's up and running, then uh on openshift, at least with crw, you log, in with your openshift user. You know we're going through openshift oauth, there's nothing to set up there and that's about it.

C

It comes with some samples that you can play around with and then you know, start diving into documentation and uh reading about how to set things up for yourself. We try to keep it pretty simple, but yeah operators, the uh main lines, are the way to install there's other tooling. We have a crw ctl, which is a command line utility that you can use to deploy automatically on your cluster. um I think there's probably links somewhere. I don't have them on hand right now,.

A

C

Find them don't worry.

A

I'll go find.

C

Links yeah, so those are the two sort of main ways to install it yourself. If you have, you know crc running locally or if you have access to a cluster. If you just want to try out the application, you just want to try code ready, workspaces out, not worry about it. Not you know deal with any setup yourself. We also have a free service hosted at workspaces.openshift.com.

C

You just sign in with. I think your red hat developer id kind of pop in there and you get a pretty decently provisioned environment, where you can try out the samples write, your own thing and uh start up a workspace, see how it works, see the architecture of the thing you can also you know, go back to the openshift console. Look at what's happening under the hood. If you're interested in that um and yeah, the only downside of the workspaces.openshift.com is that it is sort of time limited.

C

So after a couple of weeks, we kind of just wipe the account and you can. You can create a new one freely, but it's you know not intended to be your main workhorse.

A

For it should not.

C

A

Your permanent development investment- it's not your permanent bitcoin mining environment, right that too, um which.

B

You know brings up the point so that we have. There, though, is because we have a way of codifying the developer environment within the dev file, which we'll look at later. It's very easy to kind of recreate and get started again once you have repositioned on that.

C

Sun box yeah: that's that's a good thing to mention that I'm kind of glossing over. So you define your workspace and that's a portable sort of yaml file that you deploy it locally or you recreate your account. You can just take that same yaml file and get the identical thing. uh You don't actually lose data in that sense. So as long as you're pushing to you know, github and saving the dev file, you have no worries.

C

A

uh So first question does crw support plugins. I tried crw with openshift sandbox, but can't find from where to install the plugins. Okay.

C

Is this something that I should maybe share my screen for, because we can kind of.

A

Yeah I mean let's dive in and go through the ui and everything I mean that we don't have to answer that question right this second, but we need to touch it right.

C

Yeah, of course, of course, so um let me see if I can get this running the way I expect it to um so switch over here. This is uh so. This is actually oh. No, the ui is the same. It's hard to distinguish them, so this is uh this. Is the code ready workspace, uh the workspaces.openshift.com?

C

I was talking about, so it's the thing you would see. I have a few workspaces here, but um the so the editor so some background before we get into plug-ins. um We support the uh thea editor, which is based on monaco, which is the same sort of basis for vs code.

C

At the end of the day, what we're trying to do is support the vs code extension api. So any extensions you might have from your local vs code environment. You can just pretty easily import into a workspace here, so if we go through the get started, actually, let's do this way. This is a little easier to see.

C

So we go from a template. Let's just pick out, I'm using go a lot so I'll go with that. um So this is the dev file that I was talking about. This one is a little complicated because it includes some. You know: here's how you build. Here's how you run. Let me know if this text is too small. I can also zoom in a little bit more yeah. Let me know audience.

A

C

A

Read it and I'll happily ask them to zoom.

C

And you know so: here's your debug configuration you can see it's a vs code launch, so we're a lot of the time since we're using monaco you'll see that it looks a lot like you know. It looks like what you're used to if you're running vs code and a lot of the api is supported so that you can more easily port stuff over the way plugins are added here. Is we have components, it's kind of hard to see the yeah.

A

You're wrapping on the audience.

C

Requested you to oh.

D

C

There you go all right there we go so the wrapping on this is making a little bit hard to read, because the urls can get a little long, but we have a plugin elements to the sort of dev file structure. So here's my go plugin and you can see it's go. Lango latest it used to be more clear that this was just exactly the vs code. Go plugin.

C

So exactly what you're getting on vs code is what we're going to start up in your workspace. The way we do this is we. You know we're running in docker containers. You can't just grab the dependencies you need, but what we can do is start up. A sidecar container that runs go stuff, put the extension in there and then remotely access it from thea, which you know it's like it's like vs code, split into multiple containers. Basically, the other thing we have here is the docker image thing. So that's basically defining here's, a here's.

C

My you know build environment, here's my running environment! This is a pretty basic example.

C

Let me see if well, okay, let's just go. Let's just go to one. I already have defined um here's a good one, so this is one of our dog fooding dev files. So you can see we have the go plug-in. We have uh we're defining. You know the uh dev container. That has has all my dependencies already there. I don't have to worry about getting the right go version. Anything like that.

C

It has some endpoints which are kind of useful there and also starts up another container which isn't used for development but is used by the actual application, we're developing as a backend to add plugins. To finally get to the question that was asked.

D

We come with a.

C

Built-In list of plugins that we kind of maintain ourselves. um So if you go into your actual, you know workspace details, you can hit these toggles. I can you know, do this and next time I start it. It's gonna have ascii doc support.

C

um If, for whatever reason you want to have both go and java and node, you can do that. You know we can do the openshift connector that'll start up with the openshift connector from that you would use on vs code if the list that we have here isn't sufficient. If there's something that you're missing the thing to keep in mind is that we do support, I think most, if not all, of the vs code.

C

Extensions api, there's a few details where we'll hit some roughness, but it's easy to define your own plugin, especially if it's something like uh you know, there's uh I think down here is the well. The zoom has broken a scroll to the bottom, so zooming a little bit past the limits of what's expected in the ui design. Maybe um there's the ammo plug-in, for example, doesn't have any dependencies. It just runs.

C

You know you don't have to install anything to run that, so you can just take that v6 extension file and put it into there's a format and all that. But you put it into your workspace and then you have that running you can. You can basically install vs code.

C

Extensions is what I'm trying to say in a very long-winded way: nice um and there's something another little detail is going to say: oh yeah, so the language support like in vs code is provided through the language server protocol, so anything that you've got a you know language server, for that's what we're getting it from go is the uh microsoft. I think I can't remember if it's microsoft or google that builds the uh lsb for go. But you know java is the openg, the jdk java language server stuff like that.

C

So basically, when you're thinking of what do we support it's vs code, stuff that you find there is generally going to be compatible over here.

A

So two questions have uh popped up as a result of you know going through this demo. Here, one kind of the the the every pm wants to know question: can we do it in dark mode.

C

Oh, I believe we can. um I prefer light mode personally. So right I mean everybody. Has their preference right like a lot of people are used to the traditional? It should be able to go in dark mode, but the thing I can offer as a consolation is if I actually go ahead and start up one of these workspaces, we have dark mode.

A

Right yeah, so it's like.

C

The actual editor.

A

Yeah and then so that leads kind of the next question is what, if I hate the font, I'm looking at in the ui by default. Can I change that default font somehow uh yeah, so you should be.

C

Actually so I work on the back end stuff. I could be wrong on some of these details. I'm fully I'm going to be open about that. I do not work on the via component of it.

C

I work on the bits that start up pods in the background it is you know, once this gets started, it's taking some time to a bit of slowness on the cluster today, but uh once it gets started, um you'll see that it's it's going to be very similar to vs code, so you should be able to hit settings in the same way.

C

um The only issue I feel like you might run into is, if you know you have these fonts installed, it's a browser, so how browsers handle fonts might be different, but I'm pretty sure you should be able to just set that we can maybe give it a shot, see what happens. I haven't actually done that because I am personally fine with the font. I totally understand disagreement there yeah here, you can see a sort of running log of what's happening to actually get this running here. It's loading and in a moment.

C

My network probably doesn't like streaming and also running crc, no.

A

I will say that yeah, if you have a like somewhat limited upload, uh yeah you're gonna, feel it yeah. It's the joys of canadian internet. I have great.

C

Download and then I think, like 10 megabits up so yep.

A

Yeah, five of that five of that's being used for this right now, yeah exactly.

C

um So as advertised it's gonna look like vs code, um you know we have our usual ui. um I don't know why that's happening or that.

C

So yeah it's it's going to be like vs code. So, let's see what happens if we go into the preferences, look up the old font.

C

Editor, I wonder.

A

C

A

What's the preferred font, I suppose I probably have.

C

A

Code is what was asked for I've used hack, I've used uh julia, there's, all kinds of ones. I'm.

C

uh I'm a kind of guy, that's the really narrow one but still monospace um see. The problem is that I don't remember the fonts I have installed on this machine, so I.

A

Don't worry about something that no worries but.

C

A

This does very much look exactly like the vehicle.

C

It's yeah, the the underlying stuff is the same. You know it's the same: repo monaco. That's used at some point in vs code, their.

B

C

Is complicated so what parts they replace they're, not exactly sure, but the sort of soul of the thing is the same, and the contributions go both ways right. We collaborate with microsoft on their api. We contribute to some of the first language servers for vs code and then they come back into you know. Thea code ready, workspaces stuff like that.

A

So the audience is very curious: you're using the i3 window manager on what distro. This is a fedora 33 right now, nice awesome. Thank you. Yes,.

C

I I considered cropping the share screen window to just cut off fun.

A

C

Come on yeah, it's.

A

Just it's just.

C

More effective, I'm very happy that this pandemic has spurred all the sort of uh video meeting platforms to. Let me actually select a single monitor at a time it used to just show ultra wide screen.

B

C

So yeah, I appreciate it. One good thing came out of all this: the.

A

Video conferencing, tooling, has advanced yes,.

C

Yeah awesome yeah, so I don't know where is there anywhere we want to go from here? We have a thing up and running um this.

A

Is just running I mean there is one question that you know we could probably address now. I was saving for a little bit later, but rapscallion reeves, regular viewer would love to know if it's possible to have like a test instance right like so some kind of automation, around crw right like create a dev file that pulls from git, spend it up locally and get like a successful like health check or status code or whatever, and then like that way, you can do some testing kind of automatically right.

A

Like does this run enter kind of deal.

C

Yeah, I mean um it's not a use case. I've sort of experimented with um what we try to go for in general is enough flexibility to do what you need.

C

If I just stop this one up and go back to over here, let's see if this is configured in a way that makes sense for talking about this um yeah, so this so basically, this is maybe an example of what you're talking about not sure if I'm getting the exact sort of concept, but um this this data file for the plug-in broker, which is one of the things that helps startup workspaces.

C

We define this plug-in registry. This is the sort of this is the registry that the plugins are getting installed from. This is what defines sort of what container you get when you're installing uh you know the go plugin, for example, and this is just an image- we're gonna when we fingers crossed that. I didn't break this at some point in the recent times uh when we start up this, this workspace. What it's going to do is it's going to start up that image and it's just going to run. It's not idling.

C

It's basically serving plugins from within my workspace.

C

You could, in a similar way, have a container that runs tests. You could have uh you know we don't have the logic for easily defining what look running a test looks like, but if you have a container you can set the you know um command for it to you know, make test. uh However, you define your testing platform and it will just run um a few sort of minor details that we have to worry about here is the idea behind this. Is that any container you add is going to just run?

C

It's not going to stop it's not going to exit even successfully if it does, what openshift will do is it'll just say: oh, hey this, this deployment's not healthy, let's restart the whole thing exactly yeah and in general, what we try to do for all of our samples is, you know, you're going to start up your editor, um it's going to come with commands that will run your tests. It's going to come with commands that will do all of those details, so you can run tests.

C

The automation part, I'm not sure if I'm catching what the question is asking, but it's not going to it's not going to be designed for you to use it like jenkins, necessarily right, yeah and my.

A

Window just went wonky on me, hang on. Let me find the question again, of course, for whatever reason my window just went to the other, monitor and came back because that makes sense. Zoom does that on i3 for sure yeah. uh This is actually my browser window, which makes it weirder. um So if you can start the crw with a specified bash script, then I can at least make my own tests.

A

That's interesting right. Like start the environment, plug the dev file in see that it's running shut it down kind of thing right, like that's kind of the interesting work use case, I think rap scallions, considering.

C

That would potentially work. um uh You know ping me on uh there's a public uh there's the eclipse matter. Most we have a channel there. You can ask questions there and you know uh we have a quite large team working on this and I'm sure someone would be happy to help. You know depends on the details of what exactly you want to do.

C

We try to cater towards a development environment.

C

You could you know I'm trying to imagine what you're gaining by doing it through something like this, as opposed to just running a pod or a job on the cluster directly.

C

Unless you know, unless our our way of configuring, these things matches up perfectly with what you need. You know we have a simpler way of deploying something complex which is the dev file, and you know what is actually getting put on. The cluster is pretty complex in that situation, but the whole thing that comes with something simple to represent something complex is we're representing a small slice of the complexity, and if you need something outside of what we represent, then it might not work for you.

C

So that's kind of why I'm hesitating on answering this one. No, no worries I mean. While I got this running, I can just show this should just open up yeah. So this is what the registry looks like. um It's basically just showing me a readme file right now, and so, if I run this code here and say I think start, this will work okay, so I didn't actually build it first.

C

I haven't used this one in a while, and I I wrote it for myself, so it's not necessarily the best documented thing, but basically the idea is, if I run my application locally, it will use the other container in the workspace.

C

This is this is a dev container, and this is the plug-in registry container and they're both running they're both started up at the same time and configured exactly how I need them to we'll hit that compile and see how long it takes uh sorry. You were saying something before I kind of interrupted there.

A

uh I'm trying to remember chad is very active, which is good.

C

I'm happy to hear it yeah. I don't see any chat.

A

At all, so well, no.

C

A

Desert yeah, no, it's definitely not ryan. Did you want to chime in here.

D

Yeah yeah there's a yeah, a ton of people pitching in and chat. One question I had is uh and there's a couple more here we can get to as well, but I wondered if you wanted to talk to at a high level, what's the best way for teams to collaborate around dev files. Is this just another yaml that I put in with each repo, or I know you also mentioned a a registry, a dev file registry?

D

Should we have an internal registry that we share, or do I just check a dev file into each repo and then have like a launch button on github right? That sounds like an easy way to go yeah, but you know there's probably plenty of ways to do it. What's the value in the registry and is that a good way for a team to collaborate.

C

Yeah, so I mean again, you know, uh flexibility is kind of the goal. uh What we want something that'll work. uh The registry is an option for sure uh we have this built in. You know when you go here and look at this is a little broken by this and there we go and if we look at this list here, this is the built-in dev file registry um inside this are just yaml files that define the you know. Python stack, go stack java spring boot, et cetera.

C

You can build your own registry, you could store all your you know. You could say here are the dev files we use. um You could configure crw if you're deploying it locally to use your registry and then, when you navigate to this page you'll get here is my you know: here's my team's projects that we work on you just click on one instantly get a workspace.

C

The other way, which is maybe more easy or straightforward, is to store this dev file in the repo that you want to use it for. So if I go here and let's say the same, the same repo that we were just looking at here- the plug-in broker- it's a go repo and down here we have the devil, yaml and I'll zoom back in because I zoomed out.

C

If you look here, it's the same thing that we had in the ui back in the dashboard. So this defines the sort of code ready workspaces workspace for this repo and if we actually have to go to my fork, because I just fixed a little issue here that I caught. um If we go here and copy this, so you can just have a badge. um I don't think I put one. I don't think I put any on this repo. This is one of the repos I worked on in the past.

C

It's kind of been complete, more or less. I haven't had to make many updates, but you can put a badge because if you oh, I have to move that over there.

A

That wouldn't be another screen.

C

A

Make it work for you.

C

A

C

Me moving this sort of little stop share thing for me,.

A

C

A

Was covering up my url bar love that so.

C

It's always a fun feature. Yeah, it's perfect, you know, that's nobody uses the no one.

A

Uses the very top of their.

C

Screen ever right yeah, um so this is a little ugly because the sort of provisioned environment for uh the sandbox workspaces is a long url. But basically you have. This is the url to the uh code ready workspaces instance. So what I can do is just pass in what we call a factory url and pass in a link to a github repo link to a bitbucket repo.

C

You can configure sort of authorization and stuff so that you can pull from a private repo automatically. You know use some credentials to do that and what it'll do is tell me that I can't start more workspaces because I didn't shut down the previous one.

C

But let me just quickly yes, this is this is the problem I ran into okay forgot to shut that one down. So if we do that again and pass that url in it will go to github it'll grab that dev file and it'll apply it um and what we'll? What we'll get is the exact same thing? We were just looking at so short of building your own dev file registry. You can just put these files in in your in your git repos. You can also just post the files on a server.

C

um You can, you know, paste a link that when you load it will load a dev file and code ready workspaces will apply. It start a workspace from it. um So yeah flexibility, but I would say the ideal way is either keep your files in the repo and then you can just kind of you. Can this isn't a great example, but I believe oops.

C

I believe here somewhere nope. We have a badge that shows up on pr's for a lot of our components that you, you click it and it'll start up a workspace with the pr checked out. um You can click the things to run, to test to review that sort of thing, so the the easiest way is definitely here's a badge that you just click when you're in the github, ui and it'll start up a workspace for this specific repo cool yeah.

C

And trying to remember how github looks this zoomed in um is a little tricky but yeah. This is the sort of main upstream for code ready workspaces, I'm looking at yeah.

D

Awesome cool uh another question we had, and you kind of mentioned uh testing at the end of your answer on that last one: is there a good way to test a dev file or lint it um or just make sure that the repos going to successfully uh deploy uh you have any tips for automation um or how teams would approach that yeah.

C

So the design of these dev files is maybe going to be the trickiest part, um especially like until you sort of understand the sort of rules around how it's done. So, if you want to just write one of these things, there are schemas you can in vs code you can import the yaml schema if you use the red hat biamol plugin, one of the guys I work with on closely actually developed that plugin, initially four four code ready workspaces and pushed it to vs code and it's very popular there, but you know there's schemas!

C

We can. We can link this. We can say you know this shows up better on the ui when it's at the normal zoom level. um So you know missing property name. You can get some autocomplete here. So I can say I want to add an id and we get it autocomplete for the plugins that the dashboard sort of knows about. I want to add the vs code, yaml plugin.

C

um What can I add other than that? Well, I can add a cpu limit um that sort of thing. So writing the thing. You'll write a valid. You know you'll write a valid dev file. We have linting for that. The detail you might run into that is a little tricky is open shift, has rules about how you run containers um and we have additional rules about how you run containers. So, basically, the idea is any container you start up has to be non-terminating.

C

Usually we just do that by setting the entry point to you know tail devnull or sleep infinity, or something like that. Apart from that, it's kind of setting up what you want to actually run in here.

C

Ideally, the sort of samples we have are a good way of demoing these features and you can kind of pull from them. The idea behind the sort of samples that you see by default is that you say: okay, I'm working on something that uses node and it's using mongodb click. Here you have a basic skeleton of what you might want. Eventually, you know we have the plugin for typescript. We have the plugin for debugging node.

C

We have the sort of dev container. That's going to be building our node project. We have a mongodb container that gets started up. uh It's configured here, um I I don't know if I'm answering the question so stop me if I'm just kind of going off.

A

Just keep going, I think.

C

You're, okay, so yeah! Basically you know that you're, sorry.

D

Go ahead that that sounds. uh uh That was a question from rap scallion reeves, who actually had to leave so, hopefully, they'll watch the recording.

B

D

To us at some point um but yeah yeah that uh looks like it covers a lot of it for me. Is there also a way to do kind of config injection or or any other? uh um I guess you could use uh kind of standard, kubernetes secrets and other things huh yeah.

C

Yeah, the sort of underlying thing here is that um we're we're kind of abstracting over the kubernetes api. So a lot of the fields that you're seeing here are coming, you know, are mapping in some way to a container in a pod in a deployment. um You know this is the environment. I can add.

C

Command so I could define commands like I do and change the sort of entry point to my container. Endpoints is the tricky one and the sort of thing that we're kind of improving here you just define. I want an endpoint named mongodb available and we'll set up the service and the route and expose ports correctly. All of that stuff, um but yeah generally things are mapping over to um over to kubernetes or openshift um the the sort of ultimate pitch. Is you have a definition for how you're running your application on openshift on kubernetes?

C

um That's going to be a bunch of yaml, take pieces of that yaml put it into a dev file and define your workspace that way so that you know I know I need these environment variables. I know I need these entry points. I know I need these volumes mounted, define those you know take the definition you use for your production deployment, deploy it as a workspace and start editing code in the same environment that you're going to be running in eventually nice.

D

Yeah awesome um it you were showing a lot of nice kind of uh plug-in integration higher up in this file. uh We had another question uh in the chat about if whether it's possible to add plugins using the ui.

C

So add plugins to um to this dev file or in a more abstract sense.

B

Let me double check.

C

That, let's see yeah are we so if we want to add plugins via the ui, um if I go back and say, let's look at the go, plug go workspace, so if I want to add eslint, I hit this hit. Save that's from the editor here in chat.

D

B

Yeah so once you've actually got a workspace running, um basically just showing that.

C

B

C

Running workspace, yes, um I haven't tried this in a while. I'm I remember correctly. Yes, there is a way, so thea will look at the same sort of source. This is actually something that's very in flux. Right now, so the thing I've been working on for the past year uh is rewriting the sort of core provisioning logic of code, ready workspaces as a kubernetes operator.

C

So how we're doing plug-ins and stuff is kind of in flux right now, we're going to be basically the next sort of step that we're looking towards is your dev file that you use to define. Your workspace is also a custom resource that you can just directly apply to the cluster and you'll get this. um So that's what we're working towards that change.

C

That requires us to change how we handle plugins slightly, but for now I'm pretty sure that uh thea will just go to the same registry that the dashboard um you know the ui I was just showing it's called. We call the dashboard uh it'll go to the same source, look at the list of plugins and go that way. I can also talk a bit about sort of what a plugin definition looks like. um I don't know if there's a good way to do that unless I go.

C

What was the plug-in registry for this? I never remember.

D

Synthetic mousse and chat says command shift. J will bring up a plug-in menu.

C

Perfect, you know more about the.

B

I'm not sure what the mapping will be for you just in case it gets a bit yeah.

C

It'll it'll be weird on my machine because, as someone mentioned, it's i3, I have set uh everything, nothing works as I expect it to. I um I'm a clicker most of the time unless I'm using my ui.

B

Edit here's the view menu view all right.

B

C

Yeah, thank you for picking that one up yeah. I knew this existed. I just couldn't remember exactly where it was.

B

It has some nice new icons and.

C

New incoming updates.

B

Yeah, it's not this.

C

Puzzle piece anywhere, lovely yeah, so yeah I could you know, do this and now the ammo is installed. um Sometimes you have to restart the workspace. What will happen is if you know, if I install java, then the next time the workspace starts. It needs a javaside car to have the dependencies to run the java. Lsp that'll be a quick, little restart um or a long restart in firefox today. For some reason, uh apologies for that this is no worries. um This is how it goes sometimes but yeah.

C

So that's installing plugins from the ui, um the plugins are defined. Similarly as yaml files. So the other thing you can do if you don't want to go to the sort of internal plug-in registry is you can prepare one of these things yourself and the same sort of syntax in the dev file for referring to a plugin id? You can use to just paste in a url that points at a plugin points out the yaml definition for a plugin and add plugins.

C

That way, so that's one of the ways we test plug-ins is you know, someone contributes this yaml definition and I can just paste it into a dev file. Startup workspace and the plugin is running so try to make that sort of stuff easier. Nice.

C

And yeah, I guess the other thing I haven't kind of mentioned is that we also have support for so we support executing commands in these containers.

C

um That's how you would run you know, that's how you would say run the app build, the app debug, the app you can basically do any command line stuff, but once this gets loaded I'll show, you can also open terminals directly into each container and kind of just have a you know. Have a remote shell on the cluster that, let's see, if I can.

B

C

No here we go so in the go cli, so yeah, I'm just in uh standard terminal except the terminal, is basically sshing into the go dev container. I can go into.

C

Let's look what we have here, so we can go into the golang health check and we see the same same stuff. That's right here! You can use this to sort of do more detailed. You know I I'm the sort of person that goes to terminal. Very often, um I usually don't even use sort of a get ui for uh for um committing um pushing that sort of stuff.

C

I do most of my stuff from the command line, so this is the sort of thing that I look for um maybe others are different in this approach, but I like to I like to go to the command line for a lot of stuff, and so it's very easy to say, open up a command line into this and you can even go and you know I can.

C

I can open a terminal into the theater container, so this is the container that's running the sort of back end for the editor right now down here we also see the other stuff. So here's the vs code, yaml plugin, here's the vs code go plugin. You can open a terminal into that poke around all. We want um fun stuff like that.

B

It might just be worth um talking about the commands that we have at the top as well. You can define.

C

B

To make it easy for people getting started with the projects, you can give that sense of order in which that you need to run commands to be successful. Yeah.

C

Can define the commands.

B

Themselves, if there's like a segway that we recommend, so if you want one node, one, for example, uh yeah with the known project, you can all encapsulate that within yaml within the um the default itself,.

C

Yeah, so this uh whoever wrote this dev file did a much better job than I did on the one I was showing earlier, where you know we have one build the application to run the application, so you can define um you know you can define the logic for building. The idea is you're, defining the logic for everything you need so from deploying to setting up to building to testing, to pushing all of that stuff um defined in the dev file.

C

So these are basic commands. Like you know, this one is go build uh and this one is just the golang health check, which is a file in the um in the well. It's it's built by the application and put into your repo. Basically, so you know you can imagine more complex things here. You can imagine um start up your start up your postgres database and then inject this information.

C

So with one click, you can sort of set things up for testing and there are other repos. I don't have them easily on hand, but we have some. You know demo repos, that kind of get into this a little bit more set up a front end and a back end and a database, and you know a few clicks to get everything going, how you want it and then you can start debugging your code running with a front end and a back end and all that stuff.

C

A

Is there any way to customize the shell within crw that you're using? That is one question that narendev is asking? Can you switch like zsh for fish shell, for example? There is.

C

It's not currently it's not very easy. Sadly, okay, um basically.

A

C

The there's a component, um one of the plugins that automatically gets added, is the machine exec plugin. Okay, uh what that's basically doing is it's trying to resolve a shell in your workspace and kind of opening it. um It's definitely something I've done, um but it will it'll generally require building a container to do it. So when I was contributing a lot to one of our repos, that is just it's so much easier to contribute in this environment.

C

I use z, shell, um I sort of rebuilt the dev container to use z shell by default, um and once you do that it just works, but it's not. You know, I can't. I can't go into the go see up. I can't go into the go: cli dev container and install z, shell and.

B

Switch my shell, because.

C

That'll be lost as soon as the container stops right. If you know, if you build the go cli, uh if you build your sort of dev container so that z, shell is the default, then you get z, shell, okay,.

A

Interesting awesome um folks, if you got questions now's the time to ask and we're running up here on the top of the hour uh ryan, anything that I missed in chat.

D

um I haven't seen anything else new in chat. um This has been really really cool to see, though, how how this has evolved and- and I can imagine with those build and run actions. Those are basically just running docker images right, so you could kind of run just about anything anything in there and do really advanced integrations. Do you have anything that does um active interaction with the ide, like linting feedback or or anything extra that folks have added yeah? So I mean.

C

What we generally do is uh for for linting and stuff, like that, you know we're adding.

D

Probably plugins probably stuff built in, but but if you wanted something total like, I don't know, I'm imagining someone writing like an operator of some sort. I'm not sure why or how, but something to do. Maybe integration testing and show you the feedback or or something um yeah, I'm actually.

C

Not sure I think you would probably have to write a plug-in to interact with thea um I've not done it myself. So I don't know the details there yeah for for our repos. What we generally will do is you know we have the defined linter files and then, if we need a specific linter, this comes up a lot in the docs repo, because it's you know ascii doc, sort of different build chain.

C

We just add those plugins and then get that linting um for like sort of programmatically putting markers in your into your sort of files. I don't think we support that. Currently, though, you could write a plugin to do it. You can write a plugin to support that, but built-in.

D

Yeah yeah and there's there's a whole plug-in architecture for that as well. So yeah that's a a path, that's kind of already outlined and and uh yeah that's that's really cool yeah.

C

And if you, if you have a you, know internal vs code, plug-in or a private vs code, plug-in that you wrote just for yourself, you can also run it in code. Ready workspaces, get the same thing going very slick.

A

Yeah, I dropped a link to all the the vs code. Extensions redhead offers in chat. So if you're looking for particular, you know, I want that open shift, connector. Well, it's technically already there. I think right and then you know, if you need your language server, all that stuff can be plugged in. So it's just really nice.

C

A

C

It's potentially worth noting also that sort of code ready workspaces is the productized version from red hat. um The sort of set of plugins that's supported in the sort of upstream che repo is actually larger. There's you know we do a process to vet plug-ins, to check them and you know build them ourselves and support them. So there's more plug-ins in these sort of upstream repo.

C

You know the plug-ins that are available here are the ones we can vouch for nice cool.

D

um I hear that there's, I think the openshift sandbox, I'm not sure if they have the open shift connector installed in there today are you uh have you been using it in coordination with workspaces, so this is.

C

This is running on the openshift sandbox. Currently this is this is the. If you go and sign up, if you go to I mean I can never remember the full url, but the url to the crw is workspaces.openshift.com. So if you go here, this is basically what you will get. You can do everything I'm doing today from your browser. Without installing anything.

C

um I think, if I remember right, I think the openshift connector I saw earlier in the plugins list.

B

Yeah, I thought I saw it so there it is.

C

So magic, it's there, since you last checked yeah I mean.

A

We do release it every six weeks.

C

So it's moving pretty quick. Oh.

A

Cool yeah that connector or you know, is one of my favorite tools, because I often log into various clusters across the planet and yeah it's hard to keep them all sorted out just from the cli, sometimes because they'll have a name like admin. Oh that's useful, which one is that right, so yeah when I hit cube ctx, it's like ooh.

A

Let me go. Look in vs, go right! Yeah.

C

So there's a few things where I turn away from the cli and switching branches and switching clusters. Those are the two.

A

This is awesome.

C

So yeah any anything else, yeah.

A

C

Winding up to the top of the hour yeah, if there's anything else, now's the time I can stop sharing, so I can, or I can keep sharing. This probably makes more sense in case a question comes up. Could you talk.

A

About just maybe some things that are coming out, you know that.

C

You're, proud of that, I'm proud of so, as I mentioned earlier, um I'm not working directly on this code for the last little bit. The next step that we want to do is you know um if I can remember how to get back to the ui. I could show you, but you know, this is starting up a lot of services and routes and pods and volumes and all the open shift.

C

Goodness that you know you expect for a running application, so your workspace is fairly complicated under the hood, we're working on moving that logic to an operator uh and that operator it will it does. It won't replace everything but it'll replace the parts that say this piece of the dev file maps to this sort of element of a pod.

C

So we're approaching in the near future that transition point and that'll be a big change right, because currently, your dev file is just a yaml file after the change, your dev file will also be a dev workspace and you'll be able to say here's, this dev workspace and it is actually a kubernetes resource as much as a deployment is as much as a services you install the operator and that just works for you.

C

If we have time the one thing I want to shout out real, quick, it's not available on the sandbox currently, but the sort of first of the first sort of thing that came out of us working on this is the web terminal operator.

C

It uses a lot of the same logic. It uses the same component that does the terminal in your thea workspace, but what it does is it lets you open a terminal automatically log in and do openshift commands without logging into locally, without even installing oc on your local machine.

C

I don't think we have time to sort of get into the details of that. But if you look into the web terminal operator, I can share a link with chris after this. But if you look into that, that's sort of the first step in the process. um Your web terminal is defined by a dev file. Actually.

D

And you can, if you're, using uh open shift four seven or later it should be available in the hub within your cluster, and you could just search for web terminal and install it it's not on operator hub. um I was a little disappointed. I didn't see it there, but they don't have a console to integrate with. So um I don't know how how it would be displayed. You know.

C

So this is this is my crc instance, and actually um I've got web terminal installed from operator hub, oh cool, so I don't know depends on I'm sure it depends on some underlying configuration, but web terminals.

D

Yeah, I didn't see it posted on the public operator hub. I o, but yeah.

C

This is the one that that's the one I'm talking about is it'll.

B

Be in the internal hub.

C

Yeah, yes, yeah yeah, and it's been there since, I believe four five, I think four five dot four is when we first pushed it um and I'll hit this, and if we run out of time we run at a time, but basically this is applying the custom resource that represents a dev file onto my cluster and once this starts up, this is going through a couple proxies to get to it, but yeah. So here's my command line terminal.

C

I can look at the pods, and so you know it's kind of like a google cloud. Shell you're logged in you can do your cluster administration stuff from the ui of the cluster. I can pop this out into its own tab and get just a full screen terminal once it goes through the proxy.

B

With websockets but yeah so.

C

You know I'm in here I'm logged in as my openshift user, and I can do everything that I can, as that user, we're hoping to push this to the sandbox sometime soon, there's a few details to sort out but yeah. You should also expect to see this in the near future.

C

Awesome and yeah- I guess, as I was saying, if we look at my installed operators on crc, here's codery workspaces, here's web terminal, you can go through the internal operator ui and grab these and test them yourself. If you like.

D

Wonderful super cool awesome.

C

That's some really really great accomplishments.

D

Yeah yeah neat stuff.

A

It's been moving.

C

Very fast this year, so.

A

Yeah, it sounds like it and definitely feels like it. You know just the momentum we hear about on the channel in general, it's just like crw crw crw, it's great right like I love it, so yeah the little.

C

A

My github have never looked better.

D

That's how I know.

A

D

Awesome well, congratulations.

A

Seriously, yeah.

D

And thanks for coming by the show to demo it all for yes,.

C

D

C

For inviting me and I'm sure david as well sorry.

D

Yeah yeah that came out a little.

C

Weird, but I mean like no.

D

I don't wanna, I speak totally, get it.

C

Great to have you.

D

Both here yeah yeah, awesome.

A

D

A

And thank you all for tuning in and uh there's actually nothing else scheduled for today on the channel so tune in tomorrow. First thing for the level up hour at 9am, eastern uh 1300 utc. If I'm reading this right, yes and uh we'll be talking about well, uh we have a special guest coming and his name is scott mccarty. I think that's this week, if I remember correctly so definitely tune in.

A

um Yes, it is scott mccarty. I wasn't thinking ahead. ha Brain worked in your face brain, um so thank you all for joining. Thank you all for listening and we will catch. You tomorrow see.

B

B