 Okay, well welcome everyone. My name is Duncan Hardy. I'm a product manager at OpenShift and I am extremely pleased to be joined today by Jan Kleineier to probably butchered your surname there. He was manager in the developer advocate group and today we're here to do OpenShift 4 Red Roadmap update surprisingly. And some of the content in the slides does actually do that. I always struggle with audiences like this because you get a kind of a mix of people that are new is the incentive that they don't know any and certain individuals and looking at certain group over there that know the infrastructure much better than I do and who give me a shiver of fear whenever they have a question that asks me later on. So taking forward the theory of pleasing half of the people half of the time we'll do a little bit of stage setting about OpenShift 4 and we'll get into some of the features piece and then Jan will cover the developer side of things. So what are we looking at with as we wait for the slides to load? What are we looking at with OpenShift 4? Why did we do it? Why should you be using it? Why do we use technology at all? So let me go into my OpenShift 4 pitch then. So why do we do OpenShift 4? We had a look at OpenShift 3 and we looked at the areas that we thought were opportunities for improvement. So the first one that kind of jumped out to us was just install itself and we could see that people struggled with this and as soon as people actually did get an install working then they would hit the web and start looking for best practices, blueprints, all those types of things and that's what kind of gave us the impression that there was an opportunity to build in some best practice there. The other thing that we saw, I don't know, how many people have kind of got OpenShift installs now? I'm hoping to see some hands go up. Good. We're in the right room. The other thing, I guess those of you on 3, the upgrade experience wasn't great, right? It was problematic. There were so many different installs out there, so much different stuff that you could use that we, you know, the upgrade experience was not good or didn't work in some cases. So we realized there was a problem there that we could also look at. The other thing that we came to a quick realization about was that with OpenShift 3 we went out and I hope you agree that we did well with this to deliver the best Kubernetes platform offering to run your applications and workloads on. But if you look at the environment now, today you will see that there are a few other offerings. I've heard of these niche companies, AWS, VMware, you might have heard a few of them that are also offering a Kubernetes platform. And as we're all very polite to declare our Kubernetes bit is Kubernetes certified, it is just what is Kubernetes upstream. So we realized that with OpenShift 4 what we needed to do was make sure that that environment was much more than just about that thin layer of platform. We needed to differentiate it, we needed to innovate, we needed to bring you things that we did. And hence we got OpenShift 4, how are we doing? We're getting there. And hence we came to OpenShift 4. So all goodness, everyone raise their hands and cheer, tears of joy. We really are trying to take you to the land of milk and honey. And what have we done with that? Well, first of all, we want to bring you a fully automated environment, a fully integrated environment. So we've taken every component in OpenShift and we make sure that it will work together and work well together. And that's not just about the Kubernetes layer, we've pushed down into the infrastructure itself. So we'll deploy the OS for you. We'll deploy onto the infrastructure and help set that up. Check out our internet connection down here, we're hardwired and we're not getting anything. So continue. I shall continue. I'm glad I reversed this only once or twice. So we've got the integrated pieces together. Where was I? And then what next were we going to do? We wanted to make sure the install experience was much better. So one of my first tasks, I've been at Red Tat now for a year and a bit. One of my first tasks, actually, all of product management and all of engineering was to go and install 4.1 before it got onto your shelves. And having come from a shop that used to do Kubernetes, I was set aside two weeks time, kind of worried about getting everything going. And actually what happened was I found out that I needed to enter. I can't remember, and I'm looking over there, is it five or six questions into a script and off I went and had, I think it was quite late in the day. So I don't think it was a cup of tea. I think it was probably a beer. And within 30 minutes, I came back and I had a three master node work in Kubernetes cluster on our AWS cloud and we were done. So the install bit was nice, a great experience. The other thing that we did was to improve upgrade grade. So you'll see the claims and this is true because I've done it myself about one click upgrade. So we engineered the product. So now that you can really hit that one click and you can upgrade your system and it will go away and do that in a nice, joyful way and keep everything going nice and fluffy for you. And I can see. I won't make sure you get all the deal. Oh, yes. And there's always something that you get for free. And that free part is the auto skill inside. So as we developed for and we went on and made sure that we could push things up and into the cloud and, you know, examples of that are the machine API that we made available in OpenShift so that like you can scale up pods now, you can actually take your nodes and machines and scale those up on the fly. So there we go. So how do we do that? So there are two extremely intelligent and articulate gentlemen in the audience are going to talk to you about operators later on. But what we did with OpenShift was we re-engineered it from the ground up to use operators. And what that meant is we knew exactly what was on the system and more and more importantly, how to deploy what was on the system. Now, for those of you not familiar, operators are just containerized applications, but with intelligence built in. So you can take the knowledge about how to do your workflow. You can take the knowledge of some two important things and build that into the product. And that's what we've done with OpenShift. And that's why we had to re-architect it. And that's why you're seeing the things that you see today. Let me see my slides down. I'm trying to get these slides to give the gentleman in the book come down and check out our internet access. We're pointing this stuff, but the Wi-Fi is working. OK, well, all right. OK, I'm going to keep going then. So. And I'll try and remember my slides. I'm going to have to ingrain them onto a piece of paper next time. So. So we've got OpenShift four now. And we've got it working and hopefully you're using it. But you're really here for the update and to find out what's happening. So what what are we doing? What is what is ahead for OpenShift in the next year? So there are four areas and I'm going to forget one of these definitely because I haven't got my slides in front of me that we are focusing on this year. The first one and the most important piece is well, not actually most important, equally important. The first one is a little bit of surprise. I don't know about out here, but certainly one of the things that we've seen is the rapid rise of Telco 5G rollout. And is it? I always get this the wrong way around. Network virtual functions, NVF, so NFVs always get that mixed up. The Telco industry has gone nuts on that. And we've seen and what they want to do is that because they're investing in new infrastructure, is they see OpenShift has been caught to running to that. So that is one of the big bets that we're taking. And we've seen a lot of investment in that technology. The other thing that we're doing is, which is we alluded to already today, is multi-cloud, multi-cluster federation, however you want to talk it. Again, this is another one of the big bets for us. What we're seeing now is, you know, many use cases. The Telco one is one where you might have lots of small Kubernetes clusters all over. But another one is, you know, I've talked to many customers. They've got single, absolutely massive clusters with thousands and thousands of nodes. And they maybe want to break that down into smaller chunks, but still manage it in a cohesive and homogeneous way. So that's another one. And then, you know, again, to Troy's talk, we see a lot of customers that want to run on multiple different cloud providers or indeed on-prem and go into the cloud. So that's multi-cluster. Next on the list is just stability of the platform itself. So I do like to stand up here on the platform and make some great claims about how easy it is to upgrade with one click. And then within 10 minutes, someone will come up to me and say, by the way, I was doing an upgrade the other day and it failed after two minutes and you've just made all these claims. So we are investing a lot of time, a lot of effort in making sure that the platform is stable, that the experience that you get is what you expect it to be. And one of the cool things there is the telemetry piece. So, you know, if you're in connected mode and you've signed up to send back the telemetry to Red Hat, we have an entire team that's devoted at looking at that information. And what we find is, when we do an update, we'll see some customers that kind of maybe have some problems but they're not aware that they're having them so we can fix them in engineering before you ever see them, patch it and it's all done in a proactive way. And then the last one, he said, drastically trying to remember what it was, is, wow, can I have a round of applause for our team? You'd like to, if you... I think we have jabbered on long enough on certain things. Yeah, because this is the PDA. All right, okay. Oh, you'll get to see some slides that I didn't want to show, excellent. So there's the connected customer one, oops. Okay, I'm gonna keep going. And then the last one is to drive workload and usage. So this is what Jan is here to talk about. We've already alluded to this as well, developers, but the next generation of developers are extremely important to us and we want to make sure that we capture all of them. So what about Obership 4.3? Launched yesterday. I don't know how to define your definition of launch. You could have downloaded it on Friday. The announcements went out yesterday. The press release went out a couple of weeks ago. There were three areas that we kind of went into as a focus on this. So the first was the installer customization. So one of the things, and I'm looking around the room, it's certain people that I definitely got beaten up about was disconnected environment install. And we did 4.1 that was just connected only. So we've done some improvements there. And I'll talk about each of these in a little bit more detail later. Security and compliance was a focus for us. I am unfortunately old enough to remember when security was the last slide in the deck and no one wanted to talk about it. Now we all realize it's front and center. So, you know, a lot of effort there. Fibs validation and crypt RCD. We've also moved on to have Kubernetes 1.16 as our base. And the last piece is improved networking. So we've focused on high performance networking. The one that sticks out for me there, actually, is the high performance multicast. So that's really useful in IPTV and conferencing. So we did have a multicast solution, but it was pretty low bandwidth, pretty low performance. So we've gone ahead and addressed that with the help of SRIOV, which is now GA, to give you customers the opportunity to use that in those environments. So let me take a breath and slow down and start to talk about some of those things in detail. So install upgrade. We always, always get asked about which providers we support. Here's your quick list. This is pretty thin in 4.1, but, you know, now I think you will agree that the major ones are up there. As Diane's already said, Microsoft Azure and IBM Z, those are the ones that are gonna appear in 4.3 for the user you're keeping close watch. And anyone that's bought the Kool-Aid so far and busy downloading 4.3 onto their laptop to try out, you'll not see those yet. They're gonna be in a Z stream that we'll get a little bit later on. And do you wanna talk about upgrades? Has anyone looked at how you get OpenShift these days? In 4.2, we introduced the idea of three channels. There's actually four, really, though it's not an upgrade channel, so we'll talk about that too. Candidate for 4.3, seen as it's G8. Now, probably not interesting, but we'll have one for 4.4. So that gives you a little bit early access to the release before we kind of fully G8. There's a fast channel. As soon as something G8 is, as soon as the patch is ready, that goes in. So you can get it straight away. That might be just a little bit churny initially. You know yourselves when a new release comes out, we kind of do some fixing together with the telemetry that we use. So that's interesting. And then there's the stable channel where we deliberately step back, take a breath, see how everything goes, and then we'll push out kind of a lump in a more stable, updated way. The fourth way is anyone being on to try.OpenShift.com? Ooh. Ooh. Joy, if you want access, we make our nightly builds available there now. So if you want to go and get 4.4 now, get on try.OpenShift.com, all you need is a login. For example, I look after storage, the CSI snapshots functionality, tech previews just gone in there. So you can play really on it. It's really good. Likelyized with the candidate, good for test environments. So it wouldn't be put in production. Disconnected. So in 4.2, just to go back, we made the idea of disconnected start to work and how we did that was by, essentially in a simplistic way, because my mind is simplistic, is we allowed you to take a copy of our container registry and essentially stick it into your air-gapped environment and we updated all the dependencies in the operators and they allow you to grab it from there. Likewise for updates, you just pull the updates down and update the registry. So that's nice. Moving on to 4.3, as alluded to on the slide before, we've got enabled some private face and end points. So when you did a 4.2, install the ingress load balancer, for example, we'd have a public face and IP and they were certain customers, as you can expect, we're not very happy with that. I mean, you could originally just go in and do the day two operations, switch it back to being private, but some customers wanted to have a totally private install. So we've enabled that piece. We've also done, and I can also forget the second one, but vNets and whatever the other one is, thank you for that line, Patrick, we've also enabled that so you can use existing ones in the infrastructure rather than having to create new ones. And we want you there. As a slight aside, everyone's got a past. I used to work on a product where we like with OpenShift, we didn't enable you to move from one version to the next in the form of an upgrade. And there was a lot of teeth gnashing and fingernail biting and a lot of anger about that. But what I find after a while is once people got over that little bump and actually moved on to four, the anger was directed me in the way that why did you not make us move to this more quickly? Our life is so joyous now, tears, everyone wiped them away, that we should have been there much quicker. And this is the moment for OpenShift now. So four, three years out, we've got through the kinks that you might have seen earlier on, we've got a feature parity on the most important things. Your life will be much better. You will be able to enable your team to stop worrying about the drudge tasks of the day and focus on the important things for your business. This is really time to move. We've got an app that'll help you do that. What I like about this is we did look at doing an upgrade from 311 to 411, but it was gonna be a lot of resource and it was one-off engineering exercise. With this app, we envision you continuing to use this so you have your upgrade linear process, 4142, 434, 445. But so you maybe wanna stick on 422 for a while and then you suddenly realize, actually wanna move to 445. This will be the app that will help you do that. So it's a good investment for us in that it's something, a tool that you continually use but also for yourselves and it gives you flexibility of what you wanna go and where. Day two management. Another slide I didn't want you to see. This is about security. So FIPS certification. I don't know whether that's very interesting here. Certainly on North American partners for us and for that. Maybe once we get a U.S. trade agreement this year and maybe it will be more interesting to us. The other one that stands out to me, a little bit of the dog ate my homework is encryption of STD database. We had that in 311. We couldn't do it in four. It's there now so we've caught up. FIPS certification wasn't gonna show that one. Monitoring. Lots happening in monitoring. Again, between us, Jan and I could probably do a whole day on what's new in OpenShift. But what's nice here, tech preview in 4.3, you can bring your own monitoring and promissory services under the OpenShift umbrella. So if there are things that you wanted to capture before that you couldn't, now you can bring that into the umbrella. This is one of those things I'd really encourage you to try because we're actively looking for feedback for how this works and kind of to improve it. And then last at only two minutes or so far is multi-cloud. This is huge for us. I look after the Federation team. And what we realized several months ago was that we were kind of working away on our bit and the storage people were doing some things and the network and people were doing some of these things and OpenShift dedicated were doing some things but we didn't have this coordinated plan. And that's been rectified. And there are key areas now that we'll focus on. And like the telco, this is another area where we've done massive investment. There's a team being specifically spun up for this and a number of engineers, I'm not gonna say in front of the camera but come and talk to me when we're having coffee is astounding that we're putting to invest on this project. And there's some key things in there that we know now we need to address. So the provision in getting your cluster on running and the lifecycle of it, how you manage it through a UI, how you do the monitoring and log in. So the Prometheus stuff that we talked about down to the job deployment and policy pieces and the infrastructure itself. And the thing that, if you remember one thing from my section today, because I'm a multi-cloud bigot, is that what we're doing in OpenShift now is just like we did this tight change and install in four is we're now looking at every component in OpenShift and saying, okay, that has had a single cluster view to have for those components, what does it look like in a multi-cloud and multi-cluster environment? And we're going through those steps now. Specifics. So I hate putting numbers on slides, I forgot to take that off because you'll just complain at me if you don't hit the four four target. But we've got something called Hive. And this is an example of what I've talked about. So we have the machine API that allows you to roll out additional machines and scale them up and scale them down. Hive, once you have your initial cluster, OpenShift cluster will allow you to say, set up your Yaml file configuration and say, give me 20 more web hosts and clusters and it'll go and spin them up for you. And we're going to integrate that with IBM MCM. Talking of which, one of the big things for me was when we started talking to our IBM colleagues, as we noticed that IBM MCM is a jolly good solution. It actually does a lot of the things that we were thinking about how we're going to get from A to B on this already. And for those of you already with a contract with IBM and you have the multi-cloud manager in your environment, there's an OpenShift plugin for it and you can go away and manage now and get an advantage of all these things that you already done. On the red-hat side, what we're doing is looking at how we can work with that team and take things and reinvigorate the communities that we are and bring more of it over to OpenShift. And you'll see some more announcements on this soon, I'm sure. Multi-cluster networking, another one I wasn't going to talk about because otherwise Jan will not talk at all. My last slide, GitOps. If he's interested in GitOps, yeah, excellent. My buzzword of the year. We talked to pretty much all the GitOps communities and I think it was Jan's team that actually came out with the content that I'm talking about, but Argo CD seemed like the best fit for us, just where they were going and what they were going to do. So there's a bunch of content on the web available now. Really simple search for OpenShift, Argo CD and there's blogs and how tos about how to get through and get this work and we're gonna look at how we integrate things more openly. We've chosen Argo CD but we are saying we're kind of GitOps vendor agnostic so you should be able to prove if you've got weaveworks or something you will be able to plug into us but right now we're starting with those guys. And only five minutes of the time which is hopefully is not too bad. I will hand over to Jan to talk about the really important stuff which is the developer side. All right, thanks. Thank you for being patient with our slide difficulties. So I'm gonna cover two sections here. One is the first which is going to be some of the tools and services that are on top of OpenShift that are intended to help developers be more productive. So some of what we'll talk about there is service mesh, serverless pipelines and then some of the code ready tools and other developer tools. So we'll get right into it since we're running a little late. So Troy touched on service mesh a little bit. What's important for you to know that came out in 4.3 or approximately in the same timeline as 4.3 is OpenShift service mesh version 1.1 that's coming in February. Some of the key things to note about that are that it's upgrading the version of Istio that's being used to 1.4. There's also something that's coming we're gonna talk about the OpenShift console updates at the end but one of the features that's been added to the OpenShift web console is the ability to directly link to third-party dashboards and things like that. So you're able to link more easily to like the Yeager or Keali dashboards from within the web console in this new version of service mesh which is a convenience. Other things to note, so with Yeager you can use this with an external version of Elastic Search. So if you have an external version running you can use it with that now. Moving on to server lists. So server lists since OpenShift 4.2 there's actually been two major versions released so there's been a lot of progress and work going on there. The 1.3.0 version is available now I believe and that is upgraded to using Knative 0.10. It's a lot easier to install service mesh. How many have any of you tried installing it so far in the past? A couple. Well, if you haven't then just appreciate that it's much, much simpler now. In the past you had to install a bunch of dependencies, install a bunch of other operators such as service mesh under the hood before you could use server lists. Now it's just a one-click install and the OLM dependency resolution is what allows us to basically do that. So now you install it and it's going to install Istio and Yeager or all the other things that it needs in order for you to use server lists. So you should check it out. Yes. I believe our very last slide has the date on it. I don't recall the version off the top of my head but I think we have that on at the very end on our overview road map slide. So I can point that to you at the end there. But yeah, several of these features are in tech preview. If it has the red banner up there it'll designate tech preview or dev preview depending on the current state of it. OpenShift Pipelines, I believe it was Troy that may have touched on this as well. So OpenShift Pipelines is built on top of Tecton which is an open source project for doing cloud native or really kind of Kubernetes native CI CD. And what's cool about it is that it really is, it's built for containerized applications but it's also a containerized solution itself. So the way Tecton works is it brings some additional custom resources into Kubernetes in the form of tasks, pipelines, things like that. And so you can create these CI CD pipelines in Tecton and they kind of run in a very Kubernetes native kind of way. So there's no CI engine. It kind of runs serverless in that sense. Using pipelines is going to allow you to use pretty much whatever Kubernetes tools you want to use to build images and plug that into your pipeline system. So you can use things like S2I or build a, you can also use build packs or whatever works for your workflow. Pipeline's one of the features about Tecton and therefore OpenShift Pipelines as portability. So if you create these pipelines it's not just going to work on OpenShift, it'll work on any Kubernetes distribution which can be really helpful if you're trying to use things in an extensible way. It also supports reusability. So there are catalogs available of tasks that you can import and use in your own pipelines, which is nice. So OpenShift Pipelines is available in operator hub now and it also, we also have been doing a lot of work on the Tecton CLI which you use as part of managing this. In addition recently there has been a Tecton Pipelines VS Code extension. So if you're using VS Code this is available in the marketplace. This kind of builds on some of the Kubernetes extensions to allow you to create triggers, manage your pipelines and things like that from within VS Code. And then of course we are still supporting Jenkins. Some of the updates there. So the Jenkins server now supports JDK 11. It also does still support JDK 8. There's an environment variable that you can set to specify which one you want to use. There's been a couple of agents updated for again JDK 11 and also Node 10 since Node 8 is end of life I believe. And there is an official Jenkins operator and operator hub also. And that is developer preview on 4.3. But please try it out. Let us know if you have feedback. That's something that we're collaborating with the upstream community on. And it's pretty exciting to see it there. Next we'll talk about a couple of the developer tools and code ready, the code ready suite of tools that are out there. There's more than I have time to talk about here. So I'm just touching on a couple. One is ODO, out of curiosity, have any of you used ODO or Odo OpenShift Do has many names? Just a couple, okay. So what this is I'll give you a quick overview. So it is a command line tool that is really focused for developers who are doing that kind of interloop development. So maybe you're not even ready to commit these changes yet but you're doing some development. You wanna see how it's working but you wanna see it actually running. This is gonna abstract away some of those Kubernetes and even OpenShift concepts that developers may not really care to have to know in depth in order to be able to get that iterative development loop going. So you can see from the screen, hopefully you can see from the screenshot here, the syntax that you use with ODO is kind of a very familiar type of language. So you use create to create a component, push to push your changes and then you can use things like link to link affront in and back in component, create a URL. And then my favorite part is this watch command which when you're running watch it'll sit there and look for changes to your local code and as there are changes it will push them up and deploy them so you can see within a very short period of time from when you make a change and save it to when it's running on your cluster. So around the 4.3 timeline, there's been the most recent release has been a lot of fixes for stability and issues that are reported from customers. So there's quite a few things fixed there. The output that you see when you're showing a list of supported components has been improved to give you a little bit more information on kind of what levels of support for different components. And then we're also focusing now on some additional new use cases specifically around K-native additional run times that the audio can support and things like that. And then finally in this section, code ready containers. So if you're more familiar with OpenShift 3 you've probably encountered ManyShift where you can basically run a single node cluster on your laptop or desktop to do local development work. So in the OpenShift 4 world the analog to that is pretty much code ready containers. So this again will allow you to run OpenShift on your laptop or desktop. If you go to try it at OpenShift.com you can download it there. And in the 4.3 version there's been some improvements that really make it a lot easier to use specifically. This first one here, automatic certificate rotation. This smooths out a lot of hiccups that people were encountering before. So this basically will just keep it running a lot more smoothly over time for you so you don't have to deal with certificate issues. And other important notes here. If you had tried it in the past there's been a lot of fixes around networking that will allow this to be installed successfully and work as you expect in a lot more networking configurations. Especially if you do a lot of customization on your laptop around networking you'll have a better experience now. So CRC, code ready containers. It's great. We definitely love your feedback on that as well if you try it out. Just briefly gonna breeze through this content on Helm here because we don't have a ton of time. So Helm 3, if you're familiar with Helm it's basically a way of packaging and installing applications. Helm has been around for a while. What's different about Helm 3 is that there's not the server side component anymore so tiller is no longer part of it. And on OpenShift we're including Helm 3, the Helm 3 CLI in tech preview in 4.3. So you'll be able to download that. This is a very tiny screenshot but on the command line tools page where you download OC or ODO or things like that you can also get the Helm 3 CLI. So that is built, oh I almost tossed that. Built and shipped with OpenShift. The documentation is there as well and in future versions 4.4 and onward there's going to be support in the developer perspective of the web console as well for Helm charts, for releases and things like that. So it'll be additional integration to make it even more visible and easy to use in future versions. I'm going to skip this section because we've got some folks talking about operators later but I just wanna clarify that sometimes when we talk about Helm there can be a little bit of confusion because it sounds like it's solving some of the same problems as operators but they really kind of live a bit separately. So Helm is really focused around the packaging and installation but not really that day to automation of those operational tasks that happen over time. That's where operators really shine. You can have Helm-based operators but even in that case it's not gonna give you the full life cycle that other types of operators can do. So they're not two things doing the exact same, solving the exact same problems, if that makes sense. Okay, console. We've got about five minutes here. I think we can do this. So when I talk about the console I'm talking about the web interface for OpenShift. So the web console. I'm not sure how many of you have actually hands-on use OpenShift 4.2? Some, okay. So if you haven't, something really exciting in 4.2, we're talking really about 4.3 in this presentation but I wanna make sure that you're all aware. Prior to 4.2 in OpenShift 4 there was one web console and it was really very administrator focused. In 4.2 we released a perspective model. So there's an administrator view but you can toggle and go to a developer perspective which is really very application focused. We've got some screenshots here in a moment. There's a topology view that can show you what you've actually got deployed in a project and then we surface some of the things that typically going to want to do in the tasks that they perform on a regular basis but you're not locked into that. You can toggle back to the administrator view if you have more operational tasks to do. So these are some of the features that have been added to the web console in 4.3 that we wanna touch on. This is a project dashboard. So this is giving more visibility into what's going on in your projects. There's a bunch of widgets here that you can drill down into. If you can't read them, kind of what you see is project details, status inventory of what things are actually running in your project so you can click in and see your deployments, pods and so on. There's an activity log on the right hand side and then we mentioned the links that you can have like for service mesh for example to have embedded links in the console. You can see in that launcher section on the top, right? What that would look like. There's a launcher link there to open service mesh. I'm really excited about this one. So we have the ability now and not just we but you all and vendors have the ability to add YAML samples into the web console. So if you are creating custom resources you can include YAML samples so that when your users are trying to actually deploy whatever the thing is they have an example of what that YAML might look like so they're not having to always jump out and go to some documentation to see, okay how do I actually create this resource? What are the different parameters I need to deal with? So that is really exciting I think and I think that getting this in place for many of the operators, particularly ones that are out there in the community or an operator hub will make life easier when you're trying to actually deploy these things. This feature here, I'll just start off by explaining. So this is for things that are hosted in Kwe. Specifically, we have the ability to view security vulnerabilities within the web console. So that's using Claire in the future. We hope to expand to other vendors for things like Twistlock and Aqua and so on. And again for currently this is only working for images managed in Kwe. But it's pretty cool. There is a new user management section. I'm also excited about this. So to kind of simplify the user management and group management process, we've broken out under the user management section users and groups. So it was very just the pure RBAC specific kind of menus before. Now we've got users and groups and it gives a little bit easier way of managing that. Also this feature to impersonate a user can be really helpful for troubleshooting if you're trying to understand a particular user. What can they see and not see in the web console? You can do that now. You can set up alert receivers. This is kind of the first step in the process here, but to make it more efficient and more actionable for people who are receiving alerts in the system, rather than them receiving all the alerts and having to kind of filter through what's important, you can set up alert receivers to only send alerts for certain things to certain sets of people or certain applications. Right now it supports pager duty and also web hooks, but we hope to expand that to things like Slack and so on in the future. There's a couple things here around deploying applications and making that process easier. You can now deploy images from an internal registry which can be a lot more efficient. We also added in support in 4.32 auto detect the builder image. So when you're deploying something from a Git repository, it'll auto detect if it's no JS versus Java versus something else. So it just saves you a few clicks there. And then this is an exciting change too. So when you are deploying something now, in the past it would default to using a deployment config and you didn't really have an option to change it. So now we're going to default to a pure Kubernetes deployment, but you still have the opportunity to select deployment config or a Knative service as well. So you have a lot more flexibility in what your deployment target is than you did in the past. Should point out that Knative is still in tech preview, but you do have the option to do it. This is a sort of a screenshot of the topology view that I referred to in the developer perspective which shows you what you've got deployed. Some of the features that have been added in 4.3 you can toggle between this topology view and a list view of the same information which if you had 40 things deployed in there it could be a little overwhelming perhaps to look at 40 different circles, but you could look at a list view to quickly find what you're looking for. You can more easily group applications and now you can also, and an application is, you may not see the contrast here, but there's like a light gray circle around a group of these nodes on the topology view and that denotes an application. Conceptually, now you can delete an entire application and it will delete all of the components that are within that grouping. And then there's some features coming in around binding. So being able to inject configurations to connect like a front end and back end component for example to make that a little bit easier. Within the developer perspective we've added project details and project access just to say if these are things that we got feedback that would be nice to have this surfaced here to prevent having to flip back between developer and administrative perspective for some of these more commonly used tasks. So this is going to allow from the developer perspective to look at project details, but also to share your projects. So if you wanna share a project with others in your team the most commonly used roles are available there so you can give edit access or view access or whatever for your projects from within that menu. Okay, last one, we're only a few minutes over. Last one is metrics. So Duncan, you mentioned we could probably talk about all of these types of things forever. We could talk about metrics forever, but I will just point out this little bit here. So within the developer perspective we're surfacing a metrics tab. Right now it's just kind of a, this is like step one basically. So there's a dashboard here some of the most commonly used metrics. You can also use Prometheus query language to look for whatever you care about. But I expect that this will probably continue evolving over time as with all of the things in tech preview we'd love to get your feedback on what would be useful for you to look at in this developer perspective as far as metrics go. And then I did mention that there was a slide. Oh, I don't know if anyone can read that from the audience, but this is kind of a breaking it down version why. So 4.2 has been out since October 4.3 just very recently came out and then in 4.4 onward we've got the features that are coming there. I forgot which feature we were asking about when it would be in GA. It was serverless perhaps. Yeah, 4.4. The plus means probably 4.4, but I can attempt to get you more specifics around that if you catch me later in the afternoon. All right, Duncan, did you have any other things you wanted to add? All right. That's great. So I'm gonna make them stay on stage for a few more minutes. And Jay's, there were a couple of hands. Okay, we're doing really good with tech stuff today. Jay's gonna, I'm gonna give him a microphone and let him run and ask a couple questions while I bring up Christian who's going to hook up his machine. And here's one more here, Jay. And so if you have a couple of questions while we do this rigmarole with a different laptop, please do ask these guys and because I saw the hands go up a few times. Questions with Odo being around for a while in 4.3, are we looking at OC deprecation or are they gonna be complimentary? Okay, so no, we're in, OC and ODO are both important but they serve different purposes. So there's not any plans for OC to go away. OC allows you to do a much broader range of things than ODO does and that's intentional. So ODO is really meant to focus on that interloop development and to kind of do it in a way that abstracts the way that having to know what a deployment is, what a pod, what a service, what a route is and so on. So it's not intended as a replacement for OC, it lives alongside it as another option. So we have offline deployment. Code ready, workspaces, so the web-based IDE? Yes. Okay. Oh. Because currently in 3.10, you do need all the repos and stuff available. So. Offline or do you need disconnected? Disconnected. I don't know off the top of my head but I can find out unless you know. Disconnected stuff. Hi Mike. The disconnected stuff is fairly new, still kind of evolving. All of that disconnectedness, that air gapiness, all of that's already coming over for a lot of other things. For the most part, things that relies on will come if you're using weird maven repositories or something like that. I mean, once you're talking about workspaces it kind of blows up from there. There's gonna be some manual work there to bring those particular repos over but just in general it should run inside of a disconnected system. Again, assuming you've taken the dependencies you needed. It'll have the baked in run times and things like that. Kind of depends on how complicated you get things. Okay. So, and I also just hold your thoughts. At the end of today, we are gonna bring everybody back up on stage for an AMA session and everyone is going to be here during all of the breaks. So you can ask them questions there too. So we'll have a big chunk of time. I promise I'm not even gonna do my roadmap closing talk. We'll just stretch out the Q and A at the end. So find these people on the breaks, ask the questions and ask further follow up questions during the AMA. So thank you for your tolerance of our AV issues. We're gonna walk through OKV4 now with Christian Glombeck who's come to us from Berlin.