 Good morning. Good afternoon. Good evening wherever you're hailing from welcome to the developer experience office hours today We're going to be talking about simplifying and standardizing developer environments, and I have a Wonderful cast of characters here Stefan the mirror, please introduce yourself. Let us know what you do here at red hat And and then you know, yeah over to Elson. Thanks. So hi everybody. Hi Chris. Thanks for listening us today So I'm Steven Le Maure. I'm French as you can hear and I'm working as a product manager in the developer tools view where we are building a lot of different solutions for helping the developers to build their cognitive applications and We have another speaker today Elson. So Elson, please could you introduce yourself? Hello everyone? I'm Elson and I'm the active for the DevFiles services. So my team is mostly responsible for Basically what we talk about today the development of the DevFiles and all the Light-based support and all the other things around DevFiles Nice and We've done a few shows on DevFiles so far But this show is interesting because we're actually going to try and demonstrate how to make these portable They feel like So yeah, I'm curious to how you can make my life easier because Lord knows I have multiple developer environments around the house For that matter let alone, you know at work Yeah, exactly. And that's exactly what it is about. It's You know that it is a challenge to manage the different developer environments that you have There's a lot of different pain points and we are hearing most of the time The same things from all the developers or I need to configure my developer environment. I need to pull all the dependencies Shit, I have to move to one micro service to another one and there's a bunch of dependencies that are I need to reconfigure So that's what we are going to speak about today And also if you want to share your screen We have a few set of slides to introduce what DevFiles are Makes sense. And then we have some demos Beautiful awesome. So we are seeing your terminal You don't see my just one sec. I mean Try that again. The screen sharing dance is always a fun one. I Need like a sound effect Bobby. I know you're listening. It would be funny to have a screen sharing disaster sound effect Can you see it now? Yes. Okay, that's good. Awesome. Thank you Thank you. Yeah, so has Chris mentioned we are going to to speak about simplification and Standardization of developer environments, but I think more precisely we are going to speak about developer environments that are codified and repeatable so if we can go to the next slide we We know that We would love as developer spending most of our time coding, but we also have to recognize That we are spending a lot of time in things that are not exactly coding That could be managing the configuration overhead of working in Cloud native applications So you have smaller services and you want to to switch from one services to another one You want to troubleshoot that so you want to come to see how all of those services are connecting all together And there's a lot of configuration pitfalls in order to to repeat that environment on your local environment And there's also another challenge When you want to troubleshoot is that you want to Have an environment which is as close as possible to the environment from production Because what you observe on your local environment is not necessarily what is going to happen on a prod So there's a lot of discrepancies there and as a result The productivity sometime is not as good as what we would love and there's a little bit of delays in the way we can get The complete feedback loop from the local environment to the to the environment where we are going to to test our application and also run it So if we can go to the next slide, please So our mission is really about simplifying all of this and accelerating the the developer workflows and also instill consistent standards so that it helps the developers to work with their projects and to switch from one application component to another one and make sure that they are using exactly the same tools all together So next slide please We It's okay. Yeah, so So basically what we are trying to To do with with defile and codified developer environment Is to bring simplicity in the sense that we want to allow a developer to be able to code build tests run and debug without feeling any configuration pain and still having the ability to use their favorite tools could be a CLI tool could be an IDE could be different plugins for different tools all of that should be possible We want to make sure that there is consistency and alignment between the local environment the developer environment the testing environment and the production environment And make sure that the turnarounds are getting faster and that the developers can better understand how their application and all the microservice that they are building Are working all together so they can trouble shoot them in a in a much easier way as well So if we go to the next slide, please And today we know that when we develop our code, so we have our IDE configure and then we need to Compile our code. We need to build it. We need to build also the image for for our application And then we might mount The local file system or do a nursing so that each time we do changes into the source code It gets rebuilt and then we can see the changes as well And we might need to attach a debugger at some point as well. So that's a lot of manual steps There's a lot of configuration that is required to do that. It's taking a long time if it's The application components that you are working on that's easy because you have that setup basically, but if it's Another application components that you are just interacting with and that you need to pull on your local environment just to be able to to test and to debug it Then it's it's hard But all those steps most probably someone has already figure this out and So usually what you do is that you share that on a wiki page or you share that into instructions Uh, but it's difficult to keep in sync and uh, it's usually when you have a Uh, you have an intern that is joining the team That you realize that the instructions that you have on the wiki are not up to date anymore That's kind of funny, but that's usually how it happens Um, so what we do with the the def file Next slide, please. Elsa is that we put all those instructions into uh into the def file and the def file is basically a file and its format will have the the ability to To to to get this information Completely codified the file is going to live with the source code of the application So this way when you pull the source code you have the definition of the developer environment that is needed So you can just go and code So all those steps will be available and will be Understood by the tool that you are using so that's make it completely seamless and And easy to leverage in your favorite tools nice That's a little bit about the def file and Elsa if you can go to the next slide And inside of this file and inside of this format We basically provide a way to describe the the best practices for The end to end application development of your project or your application components Um, so we will have different pieces All together so we will have the information for the inner loop everything that is going to help you to to build your source code to build the the image to also Debug your source code and run it as well So you will have all of this information and you will also have The definition of the outer loop. So how you will do the deployment of your your application on a platform such as a as kubernetes for example So it includes guidance about the runtime image and the different version That you want to leverage You might have The build and the ci comments as well And the different information that will help to connect the different services all together So if we can go to the next slide, please elson So for the developer teams The architects basically What they will do is that they will define the The standard way of working by defining and writing the defy This way they can Define exactly what are the tools and what are the different components that are needed in order to to work On a particular stack could be a quarkus stack for example So what is the version of quarkus that i want to use? What are the images that i want to use to do that and what are the tools as well You might have starter projects which will help the the developers to get started and to have A sample component that they can use to kick off Building their new application component And you can also Install some compliance policies. So if you have certified a particular version of a tool or runtime or Maybe It is a best practice for you to to check for any vulnerabilities into the source code Then you can enforce that because you will have in the definition of the defy the ability to to define what is exactly Done when you are building the source code of the other project So for the developer teams That's getting a little bit easier because they can consume the defy in their tool and they With the quarkus stack for example, they will be ready to develop Instantly because they will have all the tools that they need to to start coding And they will have a guided onboarding experience as well. So they they know How they can build how they can run their their source code, but they will also Be able to leverage the starter project as well So this way it limits Yeah, sorry Yeah, so this way it limits the discrepancies between the developers Within a single team, but also between the different environments being development staging ci abroad So next slide please So who can benefit from the defiles? Obviously the stack providers and all the tools providers as well If you have a runtime a framework or something like that and you want to enable a community to To to quickly be all set to work with that runtime or that framework The defile could be a solution to provide ready-to-code developer environment For the developers They can choose the tools that works best for them And they can customize the defiles if if they want so they can extend them But they can finally focus on on coding Instead of fighting with the different configuration aspect of their developer environments So next slide please Because the way we we do that is that the defile Into all the tools that we are building within Within our our group We use the defiles as a common layer that is serving all the different tools So if you have a defile for your project, you can use that Inside of the open chip developer console You can use that with Odo which is the CLI for developers for for open shift And into all the ID That we are building and the plugins for the ID that we have as well So if you have the code you will be able to to use the defile as well And with that One thing that I haven't mentioned But inside of a defile you will have components Which are all containerized so That's what is making the defile very repeatable and easily portable As well, and that's how we leverage that across the different tools that you see here And with that I will end over to To Elson to speak a little bit more about another component from the defile which is a registry And we will have some some demos as well Nice Thank you, Stefan. So let's talk about that defile registry A defile registry is a centralized place to store defiles that tools and developers can easily access to It's an OCI based registry with some REST API that we have sitting on top of it That allows people to access the content for example getting the list of available defiles And downloading the content of the stack as well We also have a go library to interact with as well in case you want to do it programmatically So there are different types of registry like public render specific and encodsters that we'll talk about a little bit More on the next slide So here's how we link the defile defile registry and tools together A public registry for example the one at the bottom left Stores to that file provided maintained by the community Any developers can freely use the community defiles We have the official one in registry dot defile.io We're currently working on getting a better web wheel on browsing the defile in the registry as well any Are you saying that's cool? Yeah, sorry Thanks Any vendors can provide their own product registry These are typical ones with a specific product support or require locking to access the resources related to the stack For example, we're applying to have a right head product registry which contains defiles images that requires right head logging on it Users can also have have to install their own custom registry in their in their cluster as well To host their own set of defiles It can be used by for example a company to store a list of defiles That can be used by the developers to develop the applications within the organization And then regardless of which registry that that files is coming from the tools can be configured and use those and in the exact same way, so that's the beauty of that like No, you can have your own customers or you can just use the ready they make from the Community one. So everything will just work from the tools perspective Awesome So we have talked about What defiles are and who will use and benefit from them and what the defile registry is It's time to obviously see some demos So we have two demos today one is on defile with audio and the other is at defile with def workspace Cool So let me switch to My command prompt, can you see that? Yes Okay So the demo shows how defile helps developers easily using audio cli as an example tool It's just a tool that I pick happens to have a defile supporting there As part of the setup I have very done nosy logging to log into my cluster before Let's say now I want to create a brand new node.js application with defile to run on a cluster To do that, I need to create an audio component An audio component is something that maps to a defile that can build and run certain type of applications To get the list of available Audio component types I can do an audio catalog list So what it does is you take a look at what is currently basically fetched from the public Community repository that I talk about briefly And then getting the list of available that files that can be used readily be used once I notice there's actually a node.js Stack available. So let's create one with using a node.js example So do I would you create a node.js is type o in there No, j s create is no j s is the type that I see on the list That's the component type that I want to create. I want to give the name Just a random name that I give it to you. I push a I also add a Started flat in there, which indicates that I start from nothing and I want to just create a Component worth a sample application in there So if I do that You create that If I just take a look at what has been created is a really simple look jx example Here's the started project. You can see a service js file in there and there's a that file yaml You typically don't need to look at that file in details as a developers Given that this session is actually on that file. Let's take a look at that actually what's actually inside So in that file, you can find the metadata associated with that to basically tell you what that file is and some extra information associated with the that file And you can find the container Component to define how what for example what images to be used by the tools for running the runtime What the images you can use for doing the build? and the exposed to port numbers for example that this particular continuous exposing a certain port number for For running the nook server. So it will be that information is there There are also different commands in defining there as well for example build run debug and testing Basically, these are the instructions to tell Come with not coming instructions that all the tools who understand that files will know how to build and run your particular type of application So this is how that file looks like You know to run that we have given that we have done to create. It's very simple. We just do an audio push So by using this simple command, it takes the instructions from my dev file syncing the application to my cluster and then building and deploying the application to the cluster And you may notice that I can run this application on Kubernetes without much to cooperate as knowledge on Kubernetes at all Is all I did is just do an audio create and I do an audio push and that's it It typically takes a little bit faster than that probably doesn't look like the either cluster is not It's a little bit slow on this side Today, let's wait for a couple of seconds for that Yeah, so the other thing is you notice there's a couple of starters that we have We we've got different Different stacks as already available in there. So we're definitely looking at expanding the list of sacks that we have And basically What you saw inside of the def file ml is the definition of the components plus a set of commands that you can run Inside of this component. This component is a container that is getting Starting on on the cluster remotely And if you are using the vs code open chief connector, for example, it will understand Um That that component and each time you will do a build of your your source code from vs code It will also do the the build of your application directly Inside of this remote environment yeah So things are actually up and running. It actually tells you what uh url that I can use You may notice on the url that I'm using actually a sandbox uh environment Um, so um, so that means you can easily just grab a sandbox environment yourself and then try it out yourself at home so So that's that's good. Everything is up and running now If I want to make changes to application all I need to do is to change the code and run to do push again I'm not going to show that today given that we've got some other interesting things to show so, um Let's say my application needs uh, let's let's talk about surface binding. Um, let's say my application needs to use some back end services in order to function properly Now if I want to link a surface to this application in this cluster, I've got a I've installed a surface binding operator in there I can check out the list of available surfaces in the cluster using an audio command. Let me do a audio catalog this So this will list all the surfaces that's currently running on my cluster So, uh, you may notice there's a surface binding operator surface that have it running in there. Um, given that I have that I've got an example surface running I can link the example surface to my application using audio surface create command. So let's try to do that Do a create service basically want to saying that I want to create a service. I need to tell it what the Operator and the CRD is that I want to create with so basically the information that I can see from the audio service listing And that's as simple as that. I'm actually linking that to my application. So if I take a look at let's See what's actually in the Defile.mo. So you may notice there's actually a inline kubernetes Segment has been added to the defile for you as part of the command um So this one has uh got You that it gives you the name with the example surface binding in there And then the content of it is basically the service that I want for this is the spec of the service That I want for creating it based on the um was actually on the on on the example so But just do that. Uh, let's just do an audio push again. It's accessing command that I was using for pushing the application before and Just do it bill. Hopefully this time will be a little bit quicker. Hopefully I'm hoping that the sandpile sandpile ones Is uh going okay for me so um What's what it does is uh, it takes it still takes the instructions from my uh from a defile and then running through it Now it's creating uh and create a corresponding service as I associated with it. So let me do an audio service list This this command basically tells Say, okay, show me the application that has been I mean the services that have been linked to my application So it's not linked to the the one that was just great If we take a look at kube resources, let's take a look at that Just to see what's actually happening in the background um If we take a look at the kube resource, we can see from this back field You can set that the exact same information that has been defined in the defile yaml So basically we take that instructions in the defile and then translate it and then link it link the application to the surface And you may notice that on the labels, uh, it actually tells you that I'm actually linking to my applications with the That I am having it running on audio as well So this shows you how to if you just keep your glimpse of how you can actually link the surface to an application So so far we have seen the usage of staff from a community repro Let's say i'm not a more advanced users and the stack in the community repro are not enough for my usage I can create a custom registry and Use my own stacks to tailor for my development environment team So let's see how I can make use of our customer registry so In in this cluster, I've got a customer defile registry installed Let me just do a Get service so I'll show you the service that I have You may notice this extra one that I have This is a defile registry that I have installed on the customer registry on the on the cluster before If I want to see what was the URL that I can actually access to it I should just do a get route on it and copy that because I need to use that So the idea behind the customer registry is I've got this list of Another list of defiles or stack that I have available and I want to make use of it. So To link it to audio, it's fairly simple There's a simple registry command that I can just call Add to it. I give a name of a registry that I want to label. I can see see further. I'm sorry Should put a full URL to it Okay So this will make audio recognize my customer registry Now if I do an audio cattle list components again You may notice something different. So this is the new one that I have added to the registry So you I read one is the registry that I just got added You can see now that when by just doing that simple command It's now recognizing what's in the custom registry that I have I just have one single Stack in there So I can actually make use of it in the same way as what I used before. So let's let's try that and do I will do a create so You notice this now. I'm using the new type from this list. You want to look js? I'll give you an unname for that application And just do a starter for creating a simple application again So the application has been created. It's pretty much the same application as what we have before But what you notice The defile is actually different on this one because it's actually not coming from the Public community registry It's actually making use of what we call the parent support of that it interact the behavior from another Defile the user can use this parent support in defile to tailor the existing parent defiles To feed the need of the application. I can do customization on that basically Overwriting the fields from the parent. So in this particular case, I'm actually calling a parent from From our public registry for it, but just to show you This is another thing that you can actually do for that file. You can actually you know her behavior from other from other existing defiles as well. So So Just that I can just do from now on I can just do the same audio push as before and it will just run the application then I can just run the And and we just deploy as as before so you can now see that even though I'm using a custom registry the workflow from from that is It's it's all it's exactly the same as what I will be using as a public community registry and the same for our product register as well so I think yeah, so that's that's uh, this concludes the first part of the demo for using a defile with the audio ci Let's switch gear and to look at the defile usage. You see the idea environment So can I ask a question real quick? Sure about the the parent Uh defile Like what's the hierarchy there if I if I I inherit a parent, you know defile from and how do I Change a setting or you know say nah instead of You know this, you know, why release I want Of a later one kind of thing is is that possible with The inheritance process. Yes. Yes, you can so For example, if a normal defile you'll have something like this, right? You have all the fields in there difference between a parent defile once like this After you refer to a parent if you put the same sessions in here under the parent session Then it will just do an override for it Now if you just add This these element outside of the parent one then it will do an addition So that means I can actually define new containers on top of the existing parent defile and then I can just Add the same just like I'm writing the anomalous defile in that case The only difference is anything that you'll try to override you know that file From the parent you just put on the parent session then you will just work like that Cool. Yeah, basically, uh, the idea is that we have defile for stacks Which can then be uh extend for different teams With a set of different tools. So this way I can inherit from the parent definition Use that for my own stack definition And then I can even refine that For the for a dedicated project for example, so I can really tailor The defile to the needs that that I have But the the idea is really To let some people Looking at the defile making sure that they are looking great They are well shaped and they are defining the developer environment that is needed exactly The way it is needed And then the developers they don't have to worry about that They don't have to touch with the yaml. They don't have to interact that much about that With with this file. They just have to leverage it within their tools as D mode with odo, but it could be with With vs code. It could be with what we are calling dev workspace, which Elson is now going to Yeah, to show off. Yeah, and then one more point I want to point now is you may notice that defile yaml Is actually putting it right into your project source. Uh, that means you can actually check that into the team repository Just like any other thing. So I can develop it with the defile Specified and customize it already and I can change the team repository and step one can just check it out and then just run it Using a different tool and it will still behave in the same way So that's the beauty of f1 in there. That's awesome So let's go to the second demo. Um, I've got a video on that I'm going to show how defile helped to set up an idea environment using def workspace Eclipseshade has built with defile a concept called def workspace Which allows to define configure and start an IDE for your project Shade adds a segment to the defile model to define the IDE and its plugin that can be tailored according to your project's needs This allows you to set up define in the defile where you are able to modify code and test it instantly It's easy and reproducible I have a basic application for a demo is a Node.js application that use MongoDB for storing its data Let's take a look at the defile This defile has one project defined to add to the to the workspace Then it has a Node.js component, which is the container where I'm going to run my application as before with the port exposed Next the component is MongoDB container Which contains which which is configured to be used in my application above And the volume since I don't want to lose my test data between def workspace We start have a persistence volume component, which is modded to MongoDB And I have two simple commands start and stop the application So let's try it out To get started with Shade, we just need the repository URL and now I Just paste the URL into there and click create to open So we are creating a def workspace for our repository and wait until it started It may be interesting to note what's happening under the hood Let's check out our OpenShift console And the first interesting thing to take a look at is the def workspace custom resources We can see that there's one def workspace Created on the cluster Let's take a look at the def file YAML Let's look at it Under the specs section, you can see that the def file YAML has been embedded within the spec session You can see the components defined in there as before And also the volume Now one extra thing that Shade does is adding the third ID component, which automatically As if it could fit your editor by default for you So let's take a look at the bots There are four containers created for you Just for information Two of them, one is the Node.js application defined in the def file The other is the MongoDB defined in the def file And the rest of the other two are the theater editor and some utility container So let's switch back and see whether our workspace is ready or not So it's initializing the workspace now So we can see that the Eclipse J has been As a setup of their editor with the application loaded into the workspace already The def file is the one that we have before So the next step is to run our application So to run my application, I just run my run tasks To run and stop our commands that are defined in the def file It's now showing up in here I do our own command And selecting running the Node.js application So now Shade will actually Based on my def file information and then run the application So let's see I've got the application I've been running Let's try it out I'll add an entry of my employee in there to save everything goes well And let's say if I want to remove this application This user employee When I select this, it's got an error in there Now let's see, go back to, there's a bug on my application So let's go back to my application to fix it So what happens is in my application It's supposed to be doing a request parameter But I've got a typo in there for which I missed the underscore on the parameter So let's fix that And let me stop the application And then let me start it again After I save it So let me open up my browser Still up Setting up Now application is up and running If I try my deletion operation again And the operation once by So now that I've fixed the application I can just commit and push my changes to my give repository as usual So that's it for the demo Okay, so that shows Demo of that Let me switch back to my presentation So I think for the demo The thing that is pretty cool is that you have a def file You can use Che and dev workspace To get a complete developer environment That is running on Kubernetes To build a code your application for Kubernetes as well So you're directly coding from Kubernetes And you have been leveraging all the different components That are defined into the def file So that's pretty cool Actually, you can spin up a developer environment Just in a matter of few clicks And you can get going And start coding on the application So imagine that you are working on multiple microservice And you want to switch from editing one of the microservice To editing another one That's very handy Because you just have to open it into a different browser tab And you have an environment that is ready for you So that's pretty cool Pretty useful Yeah, and either on to that We also believe in developers have different Favors of the choice of their tools as well So that's why we try to develop this def file format So that you can actually use the tools that you want for it So other than audio and def workspace With def file support We have also added like a def preview On the def file supporting the OpenShift developer console The support allows you to basically import a key repository That contains the def file And then the def tool will be run In relation with you Based on the information But to use that You can create a project to contain the application As usual Just give a name for it Then you can use the import from def file tile And add an input on the repository information Or use the sample URL that we provide as part of the UI And once you do that That's it That's fairly simple And def console will just take that def file Trying to build the application for you And you can just launch the URL Any other applications in the def console So the flow is pretty much the same As all the other scenarios in def console And then other than that You can also find some samples from the developer catalog As well in def console We have also added a def file category for filtering To help you to easily find those def file sample easily Once you select one of the def file sample You can just create the app Using the same flow as what I've shown before So that's a quick intro on the def console integration on that So in these sessions we have talked about How def file works And how it can help you to develop your application How you can move across different variety of environment For example, a CLI to an IDE to a def console Yeah, so we also have also demoed How def files can be run in a standardized way I hope we have provided enough information That can help you to simplify and standardize The development environment using def file For more information You can check out our main website And our def file registry as well Def file API keep repo That's how our main repo is there We are currently working with another Music render for trying to propose a def file The def file specification together With def workspace as a CNCF project as well So I think that's it That's all we want to show today Let's know if there's any questions on that file Go ahead Sorry Yeah, the push on CNCF is something that we really believe is interesting Because we see that there's multiple tools That are having some kind of a similar approach Defining developer environment in a codified way You have things from dev containers You have it pod.tml You have other environments.tml from binder For example, and things like that So there's a lot of Kubernetes tools in the space That are looking at this problem But we believe that there is a need to work All together on a vendor-neutral aspect And a vendor-neutral specification format Which can then be used by others So it's going to be interesting And it's going to be also probably valuable to the community overall Yeah, no, as a CNCF ambassador I feel like this is something that is desperately needed in the community Or a standard way to keep people out of mangling YAML To get their dev environments up and running We need that to be something that is untouched Almost wholly to an extent These dev environments need to be repeatable Because they represent what's going to happen in prod So making that a reality is something that I think the IT industry has been struggling with for a long time But we finally have a real good chance with Kubernetes To make it a real thing that we can do And you're demonstrating that already And it's kind of nice to see Because I remember back in the day Passing around multi-gigabit vagrant images I would much rather pass around a file Or a folder directory structure of files need be To get up and running as opposed to Oh, yeah, by the way, you have to do all your development in a vagrant box And yeah So it's a good thing we're addressing as an industry and community I think at some point I saw some developers who were doing a zip Of their IDE Eclipse configuration With all the plugins and sharing that together Wow, I mean, yeah, that could work Maybe But it's only like half the problem, right? Like that's a local dev environment It's not a representation of prod necessarily, right? Yeah, and you don't get that version as well So if you need to go back in time And fix an issue on the maintenance version And you need to get an environment setup to do that How do you do this today? That's also a pain point So if we have this definition of the developer environment That is getting version along with the source code It can go a long way Awesome All right Folks, there are no questions in chat here People are watching I'm just assuming they are informed And don't have any questions But I'll give them a few minutes to drop them in if they want What's kind of, you know What's next maybe on the horizon for dev files, right? Like you just went to 2.0 I saw recently What is the next fun thing to come along kind of deal So we are currently working on a viewer for the dev file registry So this will allow to browse And see all the stacks that are available on the community registry So if anybody is interested to provide their stacks For a particular framework They could contribute that directly to the community registry We are also working on adding an outer loop support for the dev file So this will be part of the specification And along with the adoption of the tool with the dev file We are also integrating some changes And moving the specification forward so that we can adjust We are also looking at building a tool That will take any git repository And we'll analyze it to detect what is the most appropriate Or the best appropriate dev file to work on that project So that will be a good way to to to kick off And to lay the foundation of like what you need Yeah, that's cool Yeah, and then the main idea is that it's especially useful In the case where you've got an existing application That I now want to take advantage of the dev file I want to run in a containerized environment So if we can actually do the detection Tells you what is the best matching stack that you can use And you can just we just throw your dev file And then it will be part of your application That's awesome That I mean it's cool That's cool stuff Right, like point it at GitHub repo Tell me what I need and then go from there kind of thing That's truly powerful So thank you for sharing that Appreciate it So no questions in chat And if y'all don't have anything else I don't have anything else either We can wrap up You know I can give you seven minutes of your time back if you want And I appreciate you coming on showing this off for us Thanks for having us That was a pleasure Thanks for having us Yeah No problem at all And you know, hey, I look forward to hearing from you in the future too Coming up next on the channel is OpenShift Commons Briefing My calendar is being very slow There we go We're going to be talking about serverless and serverless functions with Nina saying So please tune in for that Please like, subscribe, and share wherever you may be watching from And we will see you out there on the streams very soon Thank you again to Elson and Stefan I appreciate your time today And I will bid you adieu for now Thanks everyone Thanks