 All right. Welcome. Hey, this is our first Jenkins X community office hours. Awesome. And we have actually, it's not just three of us, there's four of us. We have Sallaboy there as well. Yes, we've got one more person. Brilliant. So welcome, Sallaboy. We were looking for the senior Barcelona. Yeah, we're getting comments there. OK, cool. So what I'm going to do in this Slack channel, I'm just going to drop the Google Doc that we've got. So we're just going to try and follow some, people have some questions or anything they want to add into there for requested future demos as well. And it's really just to track some information, share some ideas as well for previous meetings as well. So oh, hello. We've got somebody else there as well. So I think we're going to try and maybe kick off just by saying hello, welcome. This is the first meeting we're having. I hope we're going to do this probably every two weeks, every Thursday, providing it works well. We get the people, it provides benefit for people. I think the aim is to try and create, start creating an environment for people that can share some ideas, some experiences, not just from ourselves, but from people that are actually from users as well. People involved in the community or people wanting to get involved in the community as well. So we've got some ideas. So Gables, I can see Gables. There we go. I can see, I can see you now. All right there. So yeah, I mean, I guess we could start. I mean, me and James have both been working on some, what we think of some cool new features this week. It's this week's new flavor of fun. But we can probably save that if maybe for a little bit if we would just maybe want to open it up to see if anybody's got any questions just to kick off with, I guess. No questions. Yeah, no questions here. Just trying the web tools for Spring Boot. Oh yeah, awesome. Giving a try to that, trying to understand a little bit more about that. I haven't used it before. So trying to catch up a little bit on that. Yeah, I always forget how to do it. I figure out one project and then completely forget. And then the next time I try, I'm like, what did I do again? There's like a dependency you add and I think there's some other things you add. And yeah, I mean, it's really cool when it works. I always forget the steps you have to go through to make a project work with the DevTools. Yeah, I'm still thinking about the sync. That sync, it's going to be tricky. So yeah, just trying to understand. Yeah, so the way we're using Dev Pods at the minute is we're doing things the long way. We're making a brand new Docker image and we're just running the new Docker image like we'd run any other image. With the Spring DevTools, the aim is to run a process and then that watches for the jar and then that reloads the jar on the fly. So we don't have to make a new Docker image. So we can just kind of copy the new jar. If you rebuild your Spring Boot jar, you can just copy that from your laptop into a running pod. And if you have the right environment variables and whatever the command line flags or whatever it is, Spring Boot acts in this watch mode and it will watch the jar and if the jar changes from a reload on the fly, which saves you pushing the Docker image and stuff. Yeah, but okay, but the DevTools needs to be running inside the pod, right? And in my machine at the same time, right? That's fine, yeah, just to fuel it out. So I think we probably want to have a Maven profile to add the DevTools jar into the Spring Boot. So you build it in DevTools mode, then you've got a Docker image with the Spring Boot app inside that the DevTools are running in there. Then we need a sync command that synchronizes the jar into the running pods, which is a little bit different to the way DevPods work, but we should be able to use the same Ksync tool under the covers. So that could give us a really nice fast, rapid, type some code, see it reload on the fly with Spring Boot. Spring Boot DevTools has got the live reload stuff as well. So you edit, if you're doing a web app and you edit the CSS or the HTML, it will reload the browse on the fly. So the DevTools are really cool. We just need to figure out exactly how we make Spring Boot DevTools work inside Jenkins X, but it shouldn't be too hard. The hardest bit is conditionally adding the DevTools in. So your POM.xml needs like a profile or something to add the DevTools. Yeah, yeah, I'm going in that direction. I will keep you posted about my findings. Yeah, yeah, awesome. Awesome, but I would love that. I think we're gonna have to, so the DevPods all work in kind of the same way because it's language agnostic, but I think when it comes to Spring Boot, we probably won't have a special way of doing things where we don't keep rebuilding Docker images. We just run the pod once and then we just copy the jar into it just to get that more rapid feedback. I mean, even when you're doing that, it's still not lightning fast. It's not fast, yeah. It's, I don't think fast would be the word we'd use. I mean, especially if you're using things like Hibernate, which can take 30 seconds just to start up. So it can be like a minute before the app reloads. If you buy JRebel, then that can get really fast just that can do incremental class loading and stuff. So if you only change one class, it can just reload that class. So that can get better. So we should maybe add in it and add on so that if you bought JRebel, we can include JRebel in the running thing, but we could probably do that in the profile. Have a JRebel profile that would just add JRebel in that as well, but ideally, one of the problems with Maven, we've got totally into Java and Maven stuff here already, but the one of the problems with Maven is there's no way to use bombs for plugins. So it's kind of hard to say, generically add the Spring DevTools capability on any project. You have to kind of modify the Pomex amount. But we could get JX import to do that. We could say, oh, this is a Spring Boot app. Let's add a profile for doing this debugging kind of stuff. Which would be kind of nice. I mean, Spring Boot is one of the most popular microservice frameworks around, so it'd be nice to have a really awesome out-of-the-box Spring Boot experience, really. Yeah, totally. Another thing that I might say around that space is that I've been testing the new Spring Cloud Gateway with the Kubernetes services query, right? So without deploying Eureka in there, so basically just using the Kubernetes registry. And I got it working, so I will share that example as well for people that might be interested. Cool. Yeah, if we can use static DNS, we talked about this a little bit on Slack today. If you can just hard code all your service names, so you talk to cheese and beer or whatever, and that's just it. There's no dollar squeak, there's no Kubernetes API or anything. Life's really, really simple. You can write services that talk to the Kubernetes West API, but I think we found this on Slack recently. To do that, you then have to add a library to talk to Kubernetes, then you have to add the service account. Then you need to add the roles in the service account so that you can query the various resources in Kubernetes. So it can take a little while to tweak your application, so it can do that. But imagine that this use case, well, where you have this gateway that automatically register routes, right? So that's kind of a place where you will need that. So I'm just trying to figure out where are the tweaks and it's working. It's even more complicated when it works. Yeah, I mean, it'd be nice to have a generic app that does the routes so that if your microservice needs that, you don't have to mess with all this service account and roles and stuff. So you just have a generic router thing that takes care of this for you. In many ways, Istio's trying to do that as well, where in Istio, you just talk to canonical endpoints, logical DNS names, and then it does all the magic behind the curtain to figure out what those really map to, whether they really are that service or does custom load balancing in the front, yes. Yeah, I think one of the things we all kind of want is for Kubernetes to make things easier. But whenever there's complexity like custom load balancers or whatever, we can wrap that in a microservice and hide it from the app so that the app, everything from the app looks really simple. It's talking to simple endpoints. And if you have a clever load balancer or whatever, that's a separate microservice and you hide that complexity in another place. And hopefully those load balancers can become generic, right? Because most of those are just querying services and looking for label selectors or whatever to decide where to go. But the apps are actually talking in a consistent way. They're the same for each application. It's the microservices then that actually handle the complexity, yeah. Yeah. I mean, one of the things I really like about the way Kubernetes tries to help us make basically the apps is if we assume DNS is a thing and that could just talk to cheese and beer and wine or whatever the services are called. And then that could just make up names of endpoints it wants to talk to. And then you can do kind of dependency injection to map those services into something real. It could be just a DNS name. It could be a pod selector. It could be an external name or it could be a microservice that does a routing for you just like your example with a gateway. But from the app's perspective, it's just a DNS name you talk to and you kind of hide that complexity. So it feels a bit like dependency injection but at the network level rather than a spring beam level. Cool. So it's just so Gareth joined us down there. Give us a wave, Gareth. Hey. Hey, Gareth. So Gareth joined us in a couple of weeks. Owens there as well who I met in Cardiff. He's, you added the Angular quick start. So which is in now and all, I think they're working. So thanks very much for that. So we've got some things we can show but does anybody have any questions about what's anything that's going on at the moment? I saw some Jason pop up there and I think he's having some issues at the moment with some Nexus settings or Jason's back. So I don't know if you can hear but we'll maybe have a look at that on Skype after the call but if there's any other questions anybody has at the moment anything that's ongoing or anything you wanna share? Yeah, I've got a question. Awesome. Sure. So I'm wondering if it's possible to have an external chart registry or how hard it is to get that running. I haven't had much time to play with this in the past couple of weeks but I'm hoping to get started again next week or two. But yeah, having an external registry and then we could restore an environment from without having to rebuild everything in the cluster. So I'm using an external registry basically and registering one in my make file, right? Yeah, we do the same ourselves which you can just do the help repo add URL in your make file to make sure that the build pod knows about the remote registry. The one tricky bit is if you need secrets to access it. Although to be fair, I think if it's an internal URL you're fine but if it's public you might wanna protect your own. So we probably need secrets for those. This is for the chart museum registry repository, yeah? Because one of the things we've actually we're actually using persistent volumes one of the things on the to-do list is actually switch that out when you're on say AKS, EKS or GKE actually use the native cloud storage rather than persistent volumes. So then you can actually totally gives you that kind of external registry itself. You can totally destroy your cluster but then you can recover all of your previous charts for example when you restore it. I think that's one of the things that's on the to-do list. I think chart museum certainly supports that. It's just we haven't configured that for Jenkins X after the box yet. Okay, awesome, thanks. Cool. So, let's go on, Jace. A quick question from Jacob there. How hard would it be to integrate Chay? It should be reasonably easy. There's a couple of issues already about integrating Cloud9 or Chay. So we added Dev Pods which are kind of the first step towards IDEs so we have build pods which are basically the pod templates used by Jenkins to do CI and CD pipelines. So that's where you find all the tools you need in your pipeline. So whatever version of Maven and Cube CTL and Helm and Gates and Scaffold and all those kinds of things you need to do CI and CD. What we've always kind of wanted is to align the tools that developers use and CI CD uses so that we're always using the same Maven, the same Helm, the same Cube CTL because you don't really want everybody's laptop to be managed separately plus then the cluster having a complete different version of everything. So we kind of want to align those. So the first step on the way is Dev Pods which I'll post the link to the chat for Dev Pods which is basically just a way of reusing the same pod templates for doing development. So you can literally just create a Dev Pod and a Dev Pod is just a pod for you to use as a developer to run Maven, run Node, do builds or whatever. And you can do incremental builds through Scaffold and post them to the chat. Now I did a little spike yesterday, yesterday before yesterday of could we have a command line option that when you're creating a Dev Pod could you add in a sidecar for an IDE? And I did a little prototype with Cloud9 which kind of nearly worked. It was almost usable. And so what we're thinking is we could have a Dev Pod and then have pluggable sidecars for Cloud9, Atom, maybe one day VS Code, Eclipse chip, whatever IDE you wish to use as a sidecar. Then the sidecar for the IDE and the Dev Pod could both use the same shared volume for the stuffy editing. And it also just kind of worked. The only thing we need from an Eclipse chip perspective is what we'd really like is the Dev Pod container has all of the tools that we want to use, like the Maven and Scaffold and all those kinds of things. We just want to get Eclipse chair to use the same container for running builds and stuff like that. So we want kind of one container that runs the web IDE bit and then all the commands we want those to run in the other container. If we can get that to it with Eclipse chair, that would be awesome. And hopefully we can do the same with other editors as well because people like all kinds of different ones. But yes, it shouldn't be too hard, I don't think. So hopefully someone can help make that happen. So with that, with that mean, because one of the things with VS Code stuff that we were looking at, really wanted to be able to make a pull request with our preview environments, then have a link to the editor really, that's what I want, is the IDE, a link browser-based with those changes kind of running somewhere. Even mounting a source code repo or some test repo, for example, that you can kind of, many of you then meant to simulate a test over it. Yeah. That would be awesome. I desperate for, to be able to just edit a pull request and just open the browser and you're in the pull request with all the code there and you don't have to do all that get magic to kind of branch, fork, pull. That would be just awesome because you often just want to tweak a pull request, right? And that's, for me, that's the killer use case for web-based IDE. I think a lot of developers are quite attached to the heavy-duty IDE, right? Like you couldn't have to really pull IntelliJ away from me with, I'm going to be holding on with my fingernails with the last breath. But there's times when I use the GitHub UI to do some changes because it's just a simple change and it's easier just to do it in the UI in GitHub. So I think for pull request, particularly when, something goes wrong with the pull request, just editing a pull request, that's a perfect use case for a web-based IDE. And that's just a question of which one? Is it Chair? Is it Cloud9? Is it something in the Atom VS Code ecosystem? I saw another one the other day that's come along. It's just a question of which one is it going to be? But yes, I would love a web-based IDE for pull requests. Just one other thing about dev pods. So right now, whenever you push a pull request, you get a preview environment. What we kind of wanted to do with dev pods was have a way of deploying things on a per developer basis before you've done a pull request. So what we kind of do, I'm not sure about the name of this, we call it edit environments. So each user gets an edit environment. We should maybe call it a personal environment or a user environment or something. But basically each person gets their own environment that if ever you run a dev pod command and you run a scaffold build, scaffold will then deploy automatically into your personal namespace. So if two of us have got dev pods at the same time when we both do a build, each of our builds will go in different namespaces so we don't kind of conflict. It would be nice if we got, say, something like chair working. We kind of want chair or Cloud9 or VS Code. We kind of want those to use the same underlying commands to do the build. So in a scaffold dev, scaffold run, or whatever the commands end up being to do the build in a run. If we get that working in an IDE, I think that would be really, really awesome. I mean, today, like I've done demos recently with dev pods and I've used a desktop IDE like VS Code and use JX Sync to synchronize my desktop editor with the dev pod. If you're using a web-based IDE, that could just be in the dev pod and then we don't need to worry about synchronizing. There can just be one persistent volume with your changes on and you can edit it in the dev pod either with Vi, if you want to keep it hardcore, or with a web-based IDE. Awesome. Can I ask one question that might be related to that? And I'm trying to figure out, it might be a very silly one, but it's related with something that also, I don't know, James, or some in this about teams, right? So how do I make my team to connect to the existing cluster around the documentation about that, right? So instead of pushing them to create a fork of the project and create their own pipelines for that, how they can join my pipelines? So how do we do that? I mean, what's the recommended approach for that? Or maybe, if you're planning to do something around it, it would be really interesting to know what's the direction. Yeah, we need to polish that experience a bit, really. I mean, today JX is using the same CUBE config to talk to the cluster that CUBE CTL is. So I mean, the first step is connect to the cluster just like you do in, say, Google Cloud or whatever. Then, assuming you have access to the no space that has the team inside, you should be able to just use all the JX commands. We could do with better commands to do, for example, it'd be nice to be able to say, clone all the repos for my team into the file system. So they're all just there. So I could just do it rather than finding me to get URL by hand, just kind of going, clone my repos, so all the team's repos are cloned in the folder. So you almost have like a workspace that gets set up for you in the file system with all of the projects. Maybe even forks them all automatically so that you're working on a fork. Some people don't like to work on a fork or can make that configurable. So it would be nice to have a single CLI that just says join team or something or team setup or something. And then that queries, what are all the apps or what are all the apps in your team? Clone all the repos to the file system and then maybe even open your IDE on them or you can manually open them all individually or whatever. That would be really, I mean, it's super simple to do because they're all in CRDs. We know what they all are. So that would be really, really nice. Yes, I'd like to do that. If ever we go web IDE, I think it'd be really easy to be able to just open editors directly from JX or from the Jenkins console or something. I think that'd be really nice. Yeah, let me make a note of the clone repos. You know, that's a really nice idea. I've been popping some notes in the GKE doc and... Oh, thank you. Although I didn't take that one there. Please. There was a question actually from Owen about, is there any kind of, is there a way to have an audit tool so they can look for bad practices of clusters? So the example was giving things of like, encryption of REST for non-secure API server, for example. I don't know if in that particular example, but the thing that sprung to my mind was Son and Boy, but I don't know. Is that what you would say, James? Yeah, I was gonna give the same answer. So one of the problems we have in general with, well, everyone has in general with anything that's Kubernetes based is nobody quite knows what a cluster looks like. And so we build all these tools and we kind of assume there's a nice working cluster. And we just write these, you know, YAML or Helm charts and we assume everything's gonna work. But then there's all kinds of different clusters out there and sometimes this well-behaving Kubernetes app doesn't work on the cluster. So having a way of just verifying is the cluster set up correctly? You know, is DNS working and so forth? Yeah, we've looked at Son and Boy and Son and Boy looks a really nice way of basically just running a bunch of compatibility tests to go, yes, DNS is working. Yes, we can talk to it via any ingress and all those kind of things. But it's so easy to mess up Kubernetes really. Oh, not mess up. Have a Kubernetes cluster that's configured so that it won't work with Jenkins X. What we kind of like to do is have a very declarative description of exactly what Jenkins X needs. Like we need role-based authentication enabled. We need an ingress. We need to be able to talk over DNS into the cluster from outside the cluster to work with web consoles and stuff. Some people want HTTPS inserts everywhere, which is great. Other people just want something that kind of works to keep the tires. So it'd be really nice if we had a way of describing what the user's trying to do, like is it HTTPS or not, which DNS name and whatever. And then we could run Son and Boy to validate is the cluster behaving correctly? But the various things that like Owen said is the API service secure, are the certs for everything, and is everything HTTPS only and all that kind of stuff. Another thing that tricks people up is today we're using insecure Docker registries, which might scare people and think, oh my God, things are insecure, but full. All that literally means is we can use a Docker registry in the cluster to store images. And we only access it via service IP. So it's not meant to be on the internet necessarily or it doesn't have to be on the internet. If it was on the internet, then it should be secure of a HTTPS, but then there's a problem. It's kind of hard to do a talk to a local registry that's running inside Kubernetes on a service IP that's not public, so there's no public certs. So it's kind of hard to do that securely. So we kind of, today the out of the box is to use an insecure registry. I think one thing we really need to do though is, every time I sure check it's extra people, they say, oh, this is how I make my clusters. And everybody's got their own shell scripts or ways or Terraform or whatever it is that they used to make clusters. We kind of want to bed Jenkins X installation into whatever people are using. So say Terraform or a shell script or whatever, so that we can have like canonical ways of, here's how you make, you install Jenkins X with cops on Amazon or G Cloud with Google or whatever. So that we don't have to mimic what people are already doing in Jenkins X. They can keep whatever it is they do to make clusters. So Google folks always use G Cloud to make clusters. Cops folks always use cops. Keep the cops and the G Cloud native and then just layer the Jenkins X install on top. Because we should be doing GitOps to manage Jenkins X, which is one of our kind of things. We cut a bit of a corner there just to get something out and get people started. But I'd really like us to have a GitOps way of managing and installing Jenkins X. So just further, so that's the actual, the initial installation where we're actually putting through monocular Nexus Jenkins, for example. And if we add an add-on currently, we just kind of apply it to that home environment team. What James is saying, yeah, we need to have that all backed by Git as well in the same way we do our other environments. But then to go to Solar Boy is coming. It'd be nice to put teams in there and users so that we can say, here's the five users on my team. I've got three teams, 10 people each. And that should be able to set up all the hour back for each user on Kubernetes. That should be a set of all the organizations and say, GitHub or whatever you're using. Give each user the read and write access to the repos in all the organizations and so forth. So that, and if ever you want to add or remove users and teams, you just edit the repo and GitOps and get Terraform, for example, to reapply your settings. So I'm really keen to get a nice Terraform installer where everything's declarative and you can use whichever Terraform add-ons you wish to use from making the Kubernetes cluster and then everything else just becomes kind of automated. Just to bootstrap the cluster, this is like, once the cluster's running, use Jenkins X to do CRNCD for all the apps. But this is more just to spin up the initial teams. I think that would be really nice. And we've got some help with that at the moment, haven't we? It's actually kind of kicked off a little bit. And there's folks from the community that kind of with Terraform expertise. And I think we are in March sometime next week as well to try and iron that out as well. So hopefully that will get to me soon, yes. I think one of the things about Terraform too is there's some nice settings and it works around it as well. So there's at least three or four which will validate the deployment for you. So I mean, which would be handy if we like use Terraform as our opinionated way of like installing Jenkins X. Yeah, yeah. Yeah, I popped a link to Sonoboy. That's from Heptio, folks from Heptio as well. That's in the chat. And they've also got some other really cool projects as well. So I'd recommend people check them out as well. Obviously the other one, Gimbal, I always forget that, is it Gimbal? Yeah, that's the low-class really kind of thing over treating clusters as catalog pets. But there's a related thing that I think really everyone should have a development cluster and then a completely separate cluster for staging and production. I mean, maybe staging and production is one cluster but it might as well be two really, if money's no object or if risk is more important than a few bucks with your cloud provider. And we don't really have a demo yet of how do we make, say, three clusters, one's for development, one's for staging, one's for production. And we completely separate them from each other so that, you know, staging, you can't even get into staging. It's locked down and production's locked down. And developers can only work in the development cluster. They can't get into prod and all that kind of stuff. So I think we kind of need a Terraform installer thingy to be able to show, here's what Jenkins looks like with, Jenkins X looks like we'd say three clusters. And each cluster could be a completely separate Amazon account or, you know, Google account or whatever. They have completely different IAMs and all that kind of stuff. And, you know, that nobody can cross clusters and we use GitOps to glue all the pieces together. Which I think would be an amazing demo because that's kind of what people really probably want to use in the real world. Having that across different cloud providers will be amazing. Exactly. I mean, it's all just Git and Terraform, right? So that should be easy. Well, yeah, and Kubernetes is as large because we're developing apps that are portable across all these clouds. Then, yeah, absolutely. The tricky bit, as soon as we start going multi-cloudies, we're going to need a bit of federation to give feedback to developers so that they might not be able to look at inside pods or definitely not look at secrets or config maps even maybe. But developers at least want to know, like, is a pod dying? You know, is a pod up? What's the restart count on pods? Be able to kind of get some kind of feedback. I mean, maybe Prometheus is the way of doing that and you just share the Prometheus rather than the Kubernetes stuff. Yeah. The feedback becomes harder when you've got multiple clusters. Maybe Gimbal can help. Yeah. Can you hear me? Yes. Yeah, I think part of the problem with sort of dev staging production is getting the images around from place to place. So, you know, obviously the AWS production is going to have its own Docker registry, presumably, rather than unless we want to go with a shared Docker registry. I've used Spinnaker a bit and like Spinnaker's kind of model is you installed Spinnaker once, perhaps sort of in your dev environment and then that can reach out to different clusters. So it's kind of got like a, there is our back in there, but it's got an elevated sort of position where it's able to do things to other, you know, so you have the clusters of, I mean, other environments. So I think whether or not that sort of leads you towards the sort of kind of an asymmetric cluster where one cluster has got a kind of elevated, you know, the dev one can do a little bit more or can tell other clusters to sort of do a little bit more. Yeah. Yeah, I've heard some folks get worried, as soon as you kind of say dev can push to prod, some security people get all kind of freaked out so that you could do push or pull, right? I was kind of thinking we might want to do a pull-based model so that to avoid dev having right access to the production Docker registry or the staging Docker registry, we might want to have a pipeline and say staging that Git has a list of all the approved images. And the first thing it does is go through all the list of the approved images in some file in Git and goes, oh, some of these images are missing. Let me pull them from the development Docker registry and pull them into, or pull and push into the production registry so that staging is locked down and only jobs inside staging can talk to the staging Docker registry and ditto for production. But you can read from other ones so that production could pull from staging to popularize registry. So we could have these, you know, one job for the environment which is allowed to move things. Maybe you want to move them out of bounds, possibly, I'm not sure, but I figure something simple like that might be a nice way of at least meeting each environment like staging production could be completely locked down and nothing can write into it unless it's a part of itself and then it pulls everything from there on. Then you've got a nice simple security policy but there's not, we could do either though, we can push and pull. The worry is, you know, a pipeline pushes by accident before it's been approved. So I kind of like the idea of using GitOps as the only way of getting images into production is a pull request. And you can have code review on every pull request to go, I don't think that image has been approved yet or whatever. You know, that image hasn't been properly tanked and it hasn't been through security checks. You could get a CI job in production, could fail the pull request if the, you know, the very anchor security scanning hasn't validated the image and all those kind of things. And it's got three plus ones from the production ops stocks or whatever. So I do like the pull model because it's easy to do GitOps with, but we could do either though. I mean, people can choose different ways. It's just a pipeline, right? So people can do what they like. Yeah, good question. Did you want, should we do a demo of something unless people have more questions and you can just shut them out? Yeah, let's do a demo. Who's going to go first? Do you want to go first or do you want me to go? Which is better, yours is probably going to be better now that you've been hacking the last couple of hours on it. I've got icons, so maybe you should go first. Yeah, all right. I've got a link. Note to self, next time tell James about the new copy after the demo, after the weekly demo. Okay, all right, let me see if I can share my screen. So while you're doing that, hello everyone, my name's Liam Newman. I'm just running the host on hosting this on the Hangouts. We're about halfway through here. There's, obviously if you're on the participant link here, you're already know about this, but on the Slack channel for Jenkins X, there's a link to actually participate if you want to be able to talk back. You can also ask questions in there. And we'll be taking notes and pulling links out of the chat window and stuff like this, so that it'll be in a Google Doc when we're done. Which I'll also add to the YouTube description when we're done with this chat. Awesome, thanks, Liam. Ah, the matrix, okay. Okay, okay, really. All right, so the new cool thing, so let me give a bit of background. Myself, James and Robert over at KubeCon two weeks ago, I think it was now in Copenhagen, excuse me. And we got, on the Friday, we got to catch up with some of the folks from Microsoft. And they were showing us some of this stuff they're doing around VS Code extensions. And they got some really, really interesting things. I actually just mentioned on the chat around also integration with, say, community service brokers so they can, you can actually, from the IDE, from the VS Code, you can actually look and find, discover services from internally, your cluster, or from the service broker, and it'll generate the actual service linking and the environment variables that you can use to copy into your code, into your workspace. So, James, I'm gonna hop in here real quick, sorry. Take your, whatever you think your font size is and pop it up until you, until the point at which you say, oh geez, that's too big. That's how big your font needs to be. Okay. Is that better? Maybe one step down from that. Well, okay, cool. Thanks. So, kind of got us thinking. We've, Jenkins X, we have the CLI, which is pretty awesome now. We're pretty happy with, we're using our day-to-day jobs as well on the Jenkins X project, to build Jenkins X. One of the things we will look in today is actually to have some kind of experience within the IDE. So, we've created a new repo, VS Code, JX Tools. There are pipelines all set up. So, you can actually run tests for the pipeline for VS Code extension. So, you can actually fork this and contributes back to this. Any contributions would be amazing. And we'll also, when things get merged, we also have pipelines and then actually publish that out to the marketplace so that it can appear in VS Code. So, it's pretty basic at the moment, what we have at the moment, but this is the, let me just give you an example of what this is very quickly. This is the project, VS Code Tools, JX Tools. When you open this up in your VS Code IDE, you probably can't see this, but on the left-hand side, there's a debug button. You can start this debug. And what this does is actually creates your brand new VS Code window. Now, let's try and make this bit bigger. What we're gonna do now is, James is gonna talk you through this bit down here, this is a Jenkins X window down here, but we're gonna add in a, start a watch, a JX watch activities. Well, hopefully we'll do this out of the box. But what we ultimately want to do is start being notified of when activities of a pipeline happen for our project, Golang Q1. So this is gonna be a pretty raw demo. So what I'm gonna do is start the pipeline for my Golang project. That's gonna trigger a job in Jenkins. You can see if anybody is familiar with the JX activity, this is actually watching the activities, which is custom resource definitions within Kubernetes. So the CLI, CLI command, JX get activity minus F Golang Q1 dash watch. So that's gonna watch using CLI. We see we've got some activity now. And if we open here, we can see now at the bottom right hand corner, we've got some notifications. Now, there's probably a few gonna be coming through here at the moment. Maybe we'll tone these down a little bit. But what we've got now is, you'll check out the source code, it'll build. We actually get a notification when this application version is deployed into a staging environment. It actually has a link as well then to open the application from the staging environment. So you can open it up from your browser. So you're just staying within the IDE. It's just something we're experimenting with at the moment, trying to give a richer experience of, just not necessarily having to leave your IDE when you're actually doing development. Probably takes a couple of minutes, you might not see this now, it's probably worse handing back to James. But this is just wanted to show some of the things we're kind of exploring with VS Code extensions and then syncing through with the abilities with Jake Jenkins X. Oh, we've got a build release and eventually we'll have a link that comes through. That was really, I just wanted to show that. James, you wanted to do a little bit more on that? Yeah, let me do a quick demo as well. That was also, by the way. Well, step sharing, let me see. Yeah, let's just see if I can share. I was just hoping to check to see if that last one popped up, no, not enough time. So, okay, next time. Okay. Yeah. All right, over to you. Can you see my screen? Oh, I need to click on you, I think. I'll maybe turn off my video. Oh, how do I turn off my video? There we go. I'll turn off my video just in case my internet's pretty dodgy. All right, I've got a little, there we go. There's my command line that's watching a Node.js thing. Here's the build here. So, this is VS Code. I'm running this in debug because I've not quite checked in all this code. I've just been working on this little folder thingy. So, you might have seen these folders in VS Code. So, there's a Kubernetes one that lets you browse Kubernetes, but this is my current namespace. And let me make this bigger. So, I can look at all the current workloads and the pods in my namespace and those kind of things. So, the Kubernetes stuff is pretty cool. So, we've now got a Jenkins X one, which is basically browsing a real-time view of all of the repos and projects that's inside Jenkins X right now. So, here we've got a bunch of different builds and if I trigger a build, we do that. You notice it's, see that little icon? Woo-hoo. We have a little icon because build six has just started. And you can see, build started there. So, we're watching in real-time all the builds that are happening in Jenkins X. So, we get a nice little animated icon that shows the builds running. If you click on it, the tooltip tells you what's happening, it's build six. That one succeeded though, the status. The build status isn't terribly useful right now. I'm hoping to put a bit more information there. We can't yet expand inside the build to look at all the different stages, but we can at least do things like open the pipeline log. This opens a browser window. Should open the browser window. We can open the repository. Why is that not working? Where's my browser with the gun? Okay, that normally works. That was working like 10 minutes ago, I promise you. View the pipeline. That's not working either. What's happened? I don't know what's happened to my browser. That was totally working. Oh, let's try this one. Let's try this one. It might be opening off. Ah, there you go. So, I can look at, it's just it doesn't have the URL yet, for the pipeline log. So, there's the pipeline log, so I can look at the log of this old pipeline, or I can go to the Jenkins page to look at the pipeline details. So, it's just a simple little way to start with browsing what's happening in your cluster. So, we're hoping to tie these two things together so that you can either browse everything that's happening in detail using this simple UI to see what's happening. We can probably do watch the browser log in a terminal to avoid opening a browser window, which might be nice. And we can do more actions than this, like start, build, stop, build, and various other things like that. And I think tying it into the stuff James just showed, where if you're working on one of these projects, you kind of want to get notified when something's happening on your project. Plus, we've got this Explorer to look at all of the other projects. So, here's my environment, for example, we've just got loads of builds, and there's a few failures down there. Yeah. So, that's it. Pretty simple stuff so far. Yeah, actually, if you just switch back, I'll just show you my other thing just worked, actually, if you don't mind. Yep, yep. And then... I need to figure out, where's the stop sharing? Right at the bottom, I think. The screen. Oh. I can actually run that a bit. You can go ahead and take it. There you go. Okay, thank you. And you can see it. Yep. So, down at the bottom here, we've got the extra notifications. So, my app has been promoted to stage and we can access the application here. So, you link that and there we go. Our amazingly colourful demo app. What we should be able to do is add in, you can actually add actions onto those notifications as well. So, perhaps we want to look at... Oh, stop sharing. Oh, okay. Actually, one second. Perhaps we do want to add some kind of promotion, maybe, on that as well. One thing, though, we can actually... This is all in the marketplace at the moment, so you can actually go to JS Code at the moment. It's definitely a preview at the moment, so don't expect too much and maybe just nothing more than what we're showing at the moment, but you can go and give that a go and test it out yourself and maybe try hacking on it as well. I think it might be pretty cool. A developer experience, though. Yeah. So, again, I think that was just the things I had, or was there anything more from you, James, or was there any comments or anything, any questions or any ideas from anybody on that? I was just going to mention how Microsoft's been doing some really good demos lately with VS Code. We're quite excited about VS Code at the moment. It's really nice. It starts up crazy quick, so it's really good for Microsoft. It's just opening projects and hacking on it. But the thing that got us quite excited was the stuff Microsoft's doing around VS Code is looking really awesome. So they've got debugging working in most programming languages already, in pods, in Kubernetes. There's already some Kubernetes tooling, which is pretty reasonable, so you can browse resources and stuff. But there's also increased tooling around things like Helm charts and using the service catalog with Helm charts, which is looking really exciting. So if you're working on an app that uses a database and you want to use a service catalog to find your database keys, find your database tokens and whatnot to access the database, there goes some pretty slick looking UI for that. So I think fairly soon, I think editing, debugging, and browsing CI CD pipelines and working with Helm and service catalog should hopefully be mostly an IDE automation thing. So people won't have to understand all of this magic YAML and go templating and all of the kind of the magic and the covers. I mean, it's not quite there yet and it needs a bit more polish, but I'm hoping in a few months we'll have a really slick developer experience with VS Code, where you can work on traditional vanilla Kubernetes, you can work on Helm, or you can work on Jenkins X or all three of them, with or without the service catalog. And I think, yes, so I think VS Code is going to be pretty awesome developing on microservices on Kubernetes. Yeah, Blue Ocean does graphs and visualizations and whatnot. So we're hoping not all of the links right now in the VS Code to live in talk straight to Blue Ocean. I'm hoping to fix that. So all the nice Blue Ocean screens appear. But we could look at doing some VS Code specific visualizations in VS Code. So we don't always have to open separate web browsers. We could do some simple visualizations inside VS Code as well. If we can get time. Cool? Cool. I was worried we weren't going to fill the hours. We've done 50 minutes. That's not too bad. Paul, there's another question. I think Spinnaker has some visualizations, pipeline progress. Right, okay. Yeah, and Blue Ocean has got some pretty nice visualization of pipelines themselves. I think one of the challenges though is the visualization in Jenkins tends to be quite generic. What we kind of want to do with Jenkins X is a bit more show, like in many ways, a build is just a build and we don't really care much about the detail too much unless it fails. What we mobile to do about is what are the environments you're promoting to? And what are the links and environments? And where's the pull request for the promotion? Where's the pipeline for the environment promotion and so on. So we kind of want that kind of, a bit like the command line shows when you do JX, let me show my screen again. When you do JX, let me turn my video off and show my screen. When you do JX get activity and you get this kind of app, this is all completely textual and it's looking just wrapping a little bit. This is almost showing you the edited highlights of what we want you to know about. Like we want to know what version's being released, what's the links in the version so I can look at it in the GitHub or GitHub or GitLab. Where are the pull requests and where are the actual applications running so I can click on the app? So it's those links really that the pull requests, the version, the CI job in the promotion and the actual app. So it's not just having a nice box diagram. It's kind of we want nice useful links so that you can drill down into that detail. Maybe the best way of doing that is through the tree widget. Maybe we just expand that in here so that you could expand a build into pipelines here and we could look at the promotion and whatnot by here possibly. But we might want some kind of UI to visualize a pipeline. A bit like Blue Ocean but maybe slightly more developer centric. Let me see if we can figure out to stop sharing. Oh, there it is. I found it. Excellent. Cool. So how's that being for people there? Has this been useful? I mean, people have stuck around. So I'm hoping that's it's been, we have a rough idea of what we're going to talk about and sometimes it's just good to let it flow but people are asking questions. Is there any feedback so far? It looks awesome. I'm really excited to see how quickly everything's moving. Awesome, yes. We like to move fast. But then there's also lots of opportunity for people to get involved as well. I was talking to somebody or there was a blog post or something we were having with somebody and it was just amazing to see the community that's building around Jenkins X I think is just going exponentially and I think that's truly amazing. James, you've put out some, you've got these metrics that come out once a month or something, different contributors of people getting involved in the project, whether that's from issues or fixing and pull requests, even just sharing, I mean, the Slack channel itself is people are helping each other and I think that's brilliant. This is just such a short amount of time. We're really hoping that this is going to kind of start, it starts to bake and more people get involved and it kind of evolves organically like this. So I think this is the start, this is the first attempt of this live hangout but there's going to be lots more ways to be involved in the community. So if people are actually viewing the recording afterwards, I just encourage you to jump on Slack as a start and it's a really welcoming place. Jenkins X Dev and Jenkins X users channels and have a look at some issues or even if you don't have, don't know Golang or don't know TypeScript for VS Code extensions, even just sharing ideas, I think is a great way to start off. So yes, okay. We could do with more ideas on the VS Code plugin particularly, like we've only just started really or Istio is another thing we're desperate for. We want to treat Istio user groups. Thanks, Jess. We really want to do environment promotions but right now we use namespaces and all clusters. We'd like to be able to do multiple promotions across environments in one cluster and one namespace. So for example, beta testers do a canary first, then do beta testers, then do employees, then do 10% of the rest of the users and do rolling upgrades across users. Kubernetes already has rolling upgrades, which is good. It doesn't yet automatically do user-based rollouts which is where Istio comes in and things like ambassador and stuff. So I'm hoping we can get that in fairly soon because I think that would be really, really useful. Yep. There's lots to do, which is good. That's a good thing. It would be really boring if everything was finished. Very good to talk about. So it's awesome. There's lots to do. Yeah. Cool. All right then. Well, if there's any last chance for any more questions or any more comments or anything, okay. Well, maybe we wrap this up and we'll have another one in two weeks' time. See you all online. Thanks so much for tuning up and being involved. Thanks so much guys. Thank you. Bye.