 All right, we are live here today. This is the OpenShift Commons Briefings Operator Hours. And today we have some very special guests here from GitLab. So we've got Darren Eastman. He's a Senior Product Manager. Hey, Darren, how are you? Hi. And then we've got Pete Rahman, who's the Federal Solutions Architect. And we've been talking this morning while we've been getting ready to get going about is winter in fact over? And can we put the snowblowers away and so forth? So probably won't be part of the topics for the conversation today, but it's certainly something that I'm trying to figure out. Anywho, gentlemen, welcome to our show here today. How are you? Great, thanks a bunch. Appreciate it, Michael. Thanks for having us. Thank you for having us. Where do you come from? You both are at GitLab. Pete, you're an SA, specifically in the federal space. What do you do there at GitLab besides being an SA? Yeah, so I am a part of the channel team. So my focus is on alliances such as Red Hat and also work with FSIs and other partners as well. So I'm in the federal side, but I'm on the channel team on the federal team. Okay, and what makes you an expert on being able to talk about GitLab and GitRunner and everything else? So this is my third year here. So I feel like I've got a little bit of time under my belt. And as well, my focus being on the channel team, working with Red Hat has been on OpenShift for the past few months or actually longer than that. My participation has been writing a lot of documentation, doing a lot of Red Hat slash OpenShift specific demos that relate GitLab to OpenShift. So that's been, I would say probably the primary focus of my role within the last year. Okay, great. Darren, how about yourself? What do you focus on there at GitLab? Tell us a little bit something about you. Yeah, thanks Michael. Hi, I'm Darren Eastman. So I joined GitLab in September of 2019, specifically as a product manager for GitLab Runner, which we'll be chatting about today. GitLab Runner is the engine that makes GitLab CI work. What makes me an expert? I guess I've been in an interest here at GitLab for just a year and a half now and working in all things Runner, which is a very interesting space because we get to touch a number of different technologies such as OpenShift. Then working with the Red Hat and OpenShift team now, I think very closely on getting the Runner operator going. Maybe for the past six or eight months. And so I wouldn't say I'm an expert, but I certainly have put it from a lot of our customers and users in terms of the features and capabilities that they're looking for. And so if that makes me an expert, we'll see. Okay, well, I would imagine that your managers and your managers, managers wouldn't have signed you up to be our victim for the show here today if you folks weren't pretty comfortable with that. So GitLab, we've been working with your team to get your operator built, tested and certified for OpenShift. Is that the, that's the GitLab Runner? That's right, that's the first one we've done. So what's the difference between the GitLab Runner and the GitLab Server, for example? That's a great question. Well, GitLab Server is, of course, the entire platform is the whole thing that makes GitLab. It is GitLab, right? GitLab Runner, it's a simple way to kind of think about it, that I kind of do, I think about it, is like it's the engine, it's the engine that makes GitLab continuous integration work. So, and continuous integration or CI, and you know, shortened in the industry, it's kind of what's making this transformation in terms of software development, in terms of velocity work, right? And so the runner is the thing that basically executes your CI jobs on a platform of choice, like in this case, Red Hat OpenShift. So it's the engine that makes the app work. It's a little thing that, you know, that basically the little engine I could, if you will. Okay, and customers can use this on-prem, public cloud, hybrid. What are the deployment modes for it? That's a great question. And that's kind of the beauty of GitLab and GitLab Runner. So in terms of GitLab Runner itself, you've made different choices. As a GitLab user or a customer, I guess kind of just stepping back, you can subscribe to our GitLab SaaS offering. So if you're in your security requirements or compliance requirements allow for it, you can just basically subscribe to GitLab SaaS. You don't actually have to install an on-premise version of GitLab or GitLab Runner. But as you well know, as everyone in the call well knows, there are different security and compliance and set up requirements. So with that, you have the flexibility of being able to install both GitLab and the GitLab Runner on-prem in the cloud, different types of choice and so on and so forth. Okay, so present company excluded with you and Pete, tell me what business problems GitLab solves for customers? Meaning like at a very high level, how do people survive without GitLab? What does it do? I mean, if someone said to me, hey, great, awesome, so you work at Red Hat, what does Red Hat do? I would say, well, we made the first enterprise commercially-supportable Linux distribution which helped our customers migrate off of proprietary Spark, Solaris platforms years ago. And then through acquisitions and technology development, we've built open stack distributions which help customers in the telco space and these days, Ansible and management and certainly OpenShift as a Kubernetes orchestration platform. What about GitLab? Like, what do you do? What problems do you solve and why are you so terrific for customers? That's a great question. In the simplest term, I'm gonna use something that I said for one of our CFOs and a cheddar he had. In the simplest terms, GitLab helps teams collaborate on software development and project management. And it's very simplest terms, right? Basically, GitLab is the one platform, the one tooling of choice for doing software development. So it's an enabler of innovation. And if you kind of think back, Michael, to maybe 10, 15, 20 years ago, how we develop software back then is completely different from how we develop software now and our expectations in terms of users as well as our executives in terms of how fast we should innovate, how fast we should deliver new features to market has completely changed. And so GitLab is that one software platform that is revolutionizing how you think about developing software. So instead of having multiple point solutions for project management, for software configuration management, for security testing, for CI CD, you have everything in one platform, in one collaboration tool. So that's basically what we solve the problem of innovating, I think, in the 21st century. That's what we're here to do. Okay. I wanted to remind you that we are live here, obviously, on our bridge and this is being picked up by Twitch and it is also being simulcast on Facebook Live and YouTube Live as well. So if people either on Facebook or YouTube have questions for Pete or Darren, please put it into the chat box and our producers will make sure that those questions get picked up and brought over here and we can get those addressed. And the same thing for those of you who are on the bridge here, please drop your questions into chat. Having said that, Pete, I'll turn it over to you. Very good. All right, so I'm gonna go ahead and share my screen if that's all right. Oh, if it's coming through, okay. All right. Are we, do you see my screen okay? I can see your screen. How many times a day do you folks hear? Can you see my screen and or, hey, you're on mute. Well, back in the day of the telephone, we'd always start with hello. I guess currently with Zoom, we always start with can you see my screen? So I think that's just the way it is now, right? I'm making T-shirts that basically has a Red Hat logo on it here and then there's gonna be two variants. One's gonna say, can you see my screen? And then the other one's gonna say, you're on mute. And so I'm making these and I'm gonna ship these out to our software partners. And I should say before you get going, the reason why GitLab is here today is because my team works with software companies to test and certify their software for the Red Hat portfolio, whether it's Linux or OpenStack or OpenShift and Ansible and so forth. Because you guys are one of our marquee customers and you guys are so interesting, we wanted to make sure that you had an opportunity to be here and talk about your technology here on our show. When we get done, if you guys want, I'd like to send you some of these shirts and you can use them on your Zoom conferences and so forth. We even won for your manager, Pete. You know, I hear he's a big T-shirt fan. Anyways, I digress. Michael, I would wear that with pride. So that's a fantastic idea. I like that. So sign me up. So yes, we can see your screen. All right, great. So let me just, you know, before I dive into this, let me explain what the object here is. Darren did a great job of explaining the runner versus the server. And I was going to kind of go along those same lines where we have two primary pieces of software, the runner and the server. And, you know, the server is kind of the brains of the operation, whereas the runner is the workhorse of the operation. And what I'm going to show you today is basically starting off in the OCP console, we're going to create a namespace. We're going to create a new GitLab project. We're going to install a runner and then we're going to actually create a pipeline using that runner and then deploy back out to OpenShift. And, you know, to kind of show you how GitLab works and how it works with OpenShift in specific. And then, you know, we'll hopefully get our application provisioned towards the end. And let me... So, Pete, while you're running your demo here, you want us to hold questions to the end and we'll just, we'll catalog them and address them when you're done with this. Yeah, that'll work for you. That way, Darren and I can attack the questions as they come in afterwards. Like I said, so we're going to start off within OCP. And, you know, first, you know, this is a brand new instance. So, first, we're going to go ahead and create a namespace for us to work in. And again, this is going to be for our fictitious company called Tanuki Tech. And what we're doing is we're creating an application which is going to be our portal that we're going to use for our fictitious company. So, once we got the namespace created, we're going to go straight to Operator Hub and we're going to search for GitLab. And you can see that we're, you know, making use of the correct namespace there so that we install it in the right namespace. We're going to go with the GitLab operator and, again, make sure that we're in the right namespace. Go ahead and install it. And so, basically, what this is doing is it's installing the operator as a prerequisite for us to actually install the runner in a little bit. So, once we have this operator installed, let's just go ahead and take a peek at it real fast and make sure everything's out there. We'll go into installed operators. We see it there. Switch over to the developer view and we can see that the operator is there. So, everything's fine and dandy. So, what we're going to do now is we're going to jump into the GitLab side of the house and we're going to actually start creating a project. And you're going to see, once we jump over there, that there's many ways to start a project. We're going to go ahead with importing a project which, again, many ways to import projects into GitLab. We're going to do a repo by URL. So, this is an existing project that's out there for our portal. We'll give it a project name, project slug and we'll change the visibility level so that anybody that's on this instance of GitLab can see this project. And now we're basically pulling in that repo into the GitLab repo. So, now that we've got the project set up, it's time for us to go ahead and start building, and this is where the fun stuff starts. This is where we start building the runners, actually installing them. So, by default, GitLab allows you to utilize shared runners throughout an instance of GitLab. We're not going to use that for right now, so I'm going to go ahead and disable that. And what we are going to do is make use of the area, the section that allows us to create a runner manually, because, like I said, runners in the server instance are two different pieces of software. Generally speaking, you're going to run the runner on a different virtual machine or different piece of hardware just to keep that utilization off the server. So, we're going to grab this token, and what I did is I actually cut and pasted it into a command that we're going to use in a little bit. And first, we're going to switch over to the correct project and excuse my slow typing. That's one thing that I was never fantastic at. And to save you the pain of watching me type a long command, I went ahead and copied this next command, and you'll see at the very end of this command, that is the token that I just grabbed from the GitLab side. So, again, this is what associates the runner that's going to be on OpenShift to my specific project. Now, runners can be done at different levels, you know, group level, at the instance level, but what I'm creating right now is a runner specific to my project. And so, that was the secret that we've done, and we're going to create a CRD file here, which I already did beforehand, so you wouldn't have to watch me actually type this. And then, oh, go ahead. We thank you for that, Pete. Yeah, well, yes, yeah, trust me on that one. So, let's go ahead and apply that and basically start building out the runner. Now, with that said, if I pop over to the OpenShift side, you're gonna see that we're spinning up a runner as we speak, so not only is this, you know, it's taking the CRD file that we used, it's building the runner based on that, and it's also registering it with GitLab. So, it's basically reaching out to the GitLab instance, basically straight to the product, or on project, and registering it with that project. So, now if I jump over to the developer viewer fast, you can see we've got our operator, we've got our runner spun up. Though it looks like we're pretty good from the OpenShift side, let's check the GitLab side as well. And like I said, so we basically registered that runner with GitLab. So now, when you go to available specific runners, you can see that there's a brand new runner there. That's the one that I just created. I'm not gonna use tags in this demo, so I'm gonna uncheck that box. And I also kinda like to track, you know, runners and make sure that I have my runners assigned to me with my name, so I'm gonna change the description out. And let's just go ahead and make sure that the changes have taken for the runner. That looks good. So, at this point, we now have a fully functioning runner, right? That's sitting out on OpenShift, ready to start taking a pipeline. Before I do that though, I did wanna dive into a very important piece of the software which is our GitLab CI YAML file. So, when you start talking about pipelines, you're gonna see that there are stages and jobs. And this is what defines those stages. It defines what's in a stage. It defines a job. It defines what's in the job. When the job's gonna be run, how it's gonna be run, what images it's using. You can see here there's scripting commands. There you see a series of OC commands in here. So, this is, and I'll come back to this in a little bit, but that's what really drives this next part which is running the pipeline. So, we're gonna dive into this. We're gonna go ahead and run a pipeline. So, we're gonna run it on master. And this is the pipeline that that CI YAML file built, right? So, you got the four stages that go across from left to right and then you've got the jobs within each stage. Now, if you were to, this is a very simplistic pipeline. If you were to add things like security scanning, license scanning, you would basically use that CI YAML file that I showed you and build those parts into these stages, right? You might create a new stage called scanning or something like that where you add these other stages into your pipeline. So, that way it's run each time that you run through. Therefore, giving you that ability to run all the scans that you need to run each time. You'll see that I did set this up to be a manual deploy just because I like to have that manual step before I actually deploy anything out into production. And what it's doing right now is it's basically doing just that, right? So, we are taking my application, my portal and deploying it out to our OpenShift instance. So, there it goes. It looks like it's been deployed. If we go over here, we can see that we now have the application out there. And we'll give it a second to spin up. And what's gonna happen is basically, it's gonna bring up our Tanuki Tech portal that we utilize for our fictitious work that we do at our fictitious company. All right, let's go ahead and fire it up, see if it works. So, there it is. So, we've got our portal. Everything looks fantastic. But there is a problem. Again, I've told you my typing skills aren't great. It looks like I fat-fingered something. So, let's go through this. And I'm gonna show you what GitLab does in terms of being able to handle the entire SDLC process within a single product. So, what we do is we use these things called issues, right? So, we go into our issue tracker. We have our issue boards. And this allows us to open up issues. An issue is something like opening up a feature enhancement request or a bug fix or something along those lines. And that's, this is where we manage those. So, maybe a tester is inputting this or somebody from a project team. So, we're gonna go ahead and open up an issue and related to this problem that we found on the website. We'll submit an issue, the issue. And, excuse me, immediately to the right-hand side, you'll see that there's various things that I can do. I'm basically assigning to this to myself just because that's who's gonna fix it. But, basically, this can be an assignee to a person or persons, multiple people, that might be actually working on this problem. You can do other things like assigning it to Epic, Milestone, work on time tracking, give it a due date. We're also gonna work with labels here. So, these are customizable labels. I'll give it a critical status so that that way, you can keep your issues labeled and organized in that way. So, diving actually into the issue, we can see a little bit more about the meat of the problem. And this is where you get a little bit descriptive. In case I'm not the person that's assigned to it, we need to make sure that the other person understands what's going on in a better scenario, in a better way. What you didn't see me do was I got a screenshot of that problem on the previous screen with the portal. And what we can do is basically take that screenshot and literally just drag and drop it into the issue, which allows us to have that picture, pictures worth a thousand words sort of a thing. So, let's go ahead and look at the preview. There it is. So, that way whoever gets this issue will understand a little bit better what to look for and what to fix. And that said, so this is a starting point for whoever put in the issue and that collaboration now begins from that issue. But then now that I'm gonna start to work on it, I'm gonna go ahead and create a merge request. The merge request is where everything, all the magic really starts to happen here, all the work really begins. You're gonna see things like commits and changes and some other info in there. What we're doing right now is we're building out a separate branch for us to actually work on. So, we don't wanna be working on master, impacting production in any way. So GitLab on the background is actually spinning up a separate bubble if you will for us to do all of our testing and viewing of the application. You'll also see there that it closes number one, which is the first issue here. So, we stay directly attached to that first issue through the merge request. So, that way there's no orphan issues, right? So, once we do this merge, it's gonna close out the issue and everything will be done so that person that's working on it can move on to the next job. And like I said, this merge request is gonna be a record of all the collaboration that occurs throughout this change. So, you can see here that we're actually, GitLab's automatically kicked off a process in the background to create a new branch, again, a sandbox so that we can do our work without impacting any production. And it'll also make use of an approval process for us to put the changes into production. But for now, now that we've got that ready for us to start working, let's start working. Now, obviously, most people might use their own local applications to do the web work or do the programming work. So, here we're using GitLab's very capable web IDE which comes as a part of the product. So, basically allows me to do the work, let's say from even an iPad while I'm on the road. So, in case you can't get to your local IDE, which is really nice. Once we make the change, we go to a split screen and the split screen allows us to see the before and after making sure that what we did is the right changes and we didn't do any inadvertent kind of changes on the side. We'll go ahead and give it a commit message and we're gonna go ahead and commit it. So, again, GitLab is very good at automating the process and making things quicker. And what you're gonna see here, if you look on the very bottom left corner there, you're gonna see us kick off a new pipeline. There it goes. We'll jump into that pipeline real fast. And so what's happening here is we're running another pipeline. Again, these pipelines are customizable to do whatever you need to do, whatever scripts you need to do, whatever scans you need to do. This is a very simplistic one. And what we're doing is deploying the application back into its own bubble. So, we're not going to production at this point, but we are taking the changes that we've made and deploying that into our bubble right now for testing. And this is a big advantage, particularly if you're gonna have approvers, approving before this application goes live. So, going back into the merger quest, I told you, this is where the rubber hits the road, sort of a thing. This is, if I was an approver, I would come in here and I'd have these various information for me to look at, such as the commits that had occurred, right? So, you only saw me do one commit. So, it's literally just that one commit at the time. You see the pipelines. And the great part about this is, if there's any part of the pipeline that didn't complete, we can hover over things and drill down on things and see what failed, how it failed, why it failed, we can get into the raw output to really start figuring out what happened. In this case, you could see that my great programming skills went straight through with no problems. You can also see the changes that were made. So, again, this is great from an approver standpoint, if they want to see all those bits of information. As, in terms of the actual approvers themselves, it can be a single approver, multiple approvers. It could be a group of people and maybe, let's say, you know, seven out of 10 people need to approve this before it goes through sort of a thing. So, just a way to keep an eye on the project and, you know, keep that authority in check. In this case, though, I'm not using any approvers. I'm just going straight through, just to save a little bit of time. So, I'm gonna go ahead and it looks like I'm ready. So, I'm gonna go ahead and do the merge. And what we're gonna do is we'll delete out the source branch, keep things clean, and we'll go ahead and merge the software. And, again, you can see the history is building out in the merge request, which, you know, you'll probably see a lot more collaboration going on in here. In realized scenarios, you would see more pipelines, more commits and a lot more activity in terms of collaboration here. We've kicked off another pipeline. So, this is, again, you know, going back to the CI YAML file, you know, we're basically using that file just to refresh your memories, to build out that pipeline. And it's, you know, it's a critical piece in the sense that, again, if you wanted to add your security scans, your license scans, or, you know, modify the jobs, do certain things, you know, this is how you do it and where you would do it. You could see on the very bottom there, you see when is manual, for instance, that, you know, that could be switched to automatic or just removed out to allow the process to go all the way through without that manual step that I added in. It's a sanity thing for me. I just like to be able to push the manual button right there as needed. So, okay, so what's happening here is we're actually deploying that out to our production instance. So now it's going back out to our open shift instance as a repaired application. So now that it's completed, it looks like everything is completed okay. You can see that the merge requests are gone. The one is closed out. And that, in turn, if we go into our issue boards, you can see it's, the issue is no longer open. So we keep everything integrated with each other so that that way, you know, from a project management standpoint, everything's nice and clean. And we'll head back to open shift. And we'll check to see how our application is doing. How often does your demo fail, Pete? With the demo gods, you know, it's, we do pretty good. I will say that the unfortunate part is I'm actually running OpenShift on my laptop in a CRC image. And so sometimes my laptop screams for help, but generally speaking, we're pretty good. Yeah, I saw that in the comments when you were in the config files there, it was like Pete's MacBook 16 or something, right? Yeah, I don't have an OpenShift instance available to me at the time, we are building that. But just to recap kind of, you know, what we did there is, you know, we started off an OpenShift, we created a namespace, then we added the operator in, we popped over to GitLab, we created a new project, and from there we created the new runner, put that into OpenShift. We then were able to provision our first version of the application out to OpenShift. Once we did that, you know, then that's where we kind of went through the entire software development lifecycle within a single application, where, you know, we saw that there was a problem, we opened up an issue, we went immediately into the merge request to work on that problem, where we did all sorts of, you know, security scanning, license scanning, and all the tests that we need to run on those things, we went through an approval process. Once that was allowed, then we basically provisioned that application back out to OpenShift. So I want to stress, you know, from a software development lifecycle standpoint, GitLab is that single pane of glass where we handle everything, you know, all the phases of that lifecycle within a single product. And I guess that's kind of it, Michael. So I have a couple of burning questions here for you. You're not being paid to be on here today, are you? I am not. Was that an option? No, I just, I mean, it's almost like this was an advertisement for Red Hat OpenShift. And like certainly, you know, like watching your demo, it was like, you know, OpenShift, OpenShift this, OpenShift that, you know, in every, you know, you know, it was just all over the place. So it was all over the place in a good way or a bad way? Well, in a good way, but I mean, it's like, you know, does GitLab run on other platforms? And if so, what are they? Yeah, absolutely. Yeah, so, go ahead, Darren. I know you take the GitLab silver piece and I'll take the run a piece of it, go ahead. Yeah, so we definitely do. We have many deployment options available. So obviously the various Linux instances, but, you know, as well as, you know, we have SaaS available as well. So you can use gitlab.com. You can use deploy GitLab out in AWS, GCP, OpenShift, obviously. So we've got every option as well as standalone option too. So I'm in the federal space. So the majority of what I see is really standalone instances. So yeah, so we definitely have that ability. And, you know, one of the things that I wanted to point out to you, you know, you were saying earlier that's GitLab, you know, we were talking a lot about OpenShift. I kind of want to point that as a very big benefit of GitLab. So as a standalone product, we are, you know, fantastic. We cover the entire life cycle, but in reality though, we need to be able to integrate with other products and integrate well with other products. So you were saying, you know, hey, if you were talking about OpenShift this, OpenShift that, well, that was actually by design because, you know, we do integrate very well with a lot of products. And OpenShift is definitely one. You were very big, your Red Hat's very big to us. We're a very big partner of you and, you know, we want to make it clear that, you know, we integrate well with other products. Okay. Well, thank you for that. So, Darren, there's the GitLab Runner, right? Which was, you folks certified your operator for use with OpenShift, I think like what? Two or three weeks ago or something? Yeah, that's all right, yep. How does that make GitLab better, having that operator? Honestly, it makes me think GitLab better. I think that's kind of picked up on what Peach has said, right? GitLab's vision is to develop this platform where, again, you have one platform for your entire software development lifecycle. The reality of the computing industry is we've got multiple types of computing platforms, Red Hat OpenShift on-prem, Red Hat OpenShift in the cloud, right? Different public cloud providers, IBM, mainframes and so on. And so we have to meet those customers or users where they're at. So the GitLab Runner on OpenShift basically just enables that on OpenShift. You're asking the question of Peach earlier in terms of other platforms that we support. The Runner, for example, you can currently, today, you can host the Runner that CI Engine for GitLab on an IBM Z mainframe. You can host it on public cloud platforms. So that's really necessary to make it better. We're just making sure that we meet our customers where they're at, because we know our customers and users have different environments that they support as they continue their evolution, as they continue their digital transformation. Okay, I'm gonna, we just got our first question from Greg Weyer. But before we go to that, I'm gonna just steal the screen here. And I'm gonna now ask the question, can you see my screen? That's brilliant. When can I get my T-shirt? That's my question. So I will, we'll get like 10 or 15 of those made for your team and we'll ship them over to you. We just need your logo. What I'm gonna say though, is Greg Weyer, you just asked the first question. So we're gonna ship you one of these Red Hat GitLab shirts as well. You can either have, can you see my screen? Or we have the second version, which is gonna be, you're on mute. So if we have any more interesting questions that people wanna ask, don't be shy. Pop them into chat and we'll make sure we get you your very own GitLab Red Hat. Can you see my screen shirt? I'm gonna stop sharing now and we're gonna go back to the question. And by the way, Greg Weyer, shoot me an email. It's just wait at redhat.com, W-A-I-T-E at redhat.com. And hopefully you're in North America. I don't think we're gonna be shipping these, these are limited edition 2021 shirts, by the way. We'll do another one for 2022, but send me your mailing address and we'll get a shirt off to you and anyone else. Okay, Greg Weyer, will residual files on the runner be cleared between jobs? Or do you have to ensure everything is removed in the CI script? I was gonna ask the very same question, but I'm glad that he did. Yeah, the answer is yes. So the answer to the question is yes. We also have a feature that we're currently working on in a next release to also do some additional cleanup of the pods on OpenShift, or specifically the runner pods on OpenShift, but at a high level, to Greg's question, the answer is yes. So residual files will be cleaned up. Will be cleaned up. Okay. Anyway, so we were talking about the runner was certified not that long ago. What about the server and how does that... So if a customer is running OpenShift in their environment, right? Whether it's in public cloud, multi-cloud, on-premise, whatever, they can use the runner operator. What's the relationship between the server and OpenShift? Where's that? Is that all in your data centers? And is that the SAS component of it, which the runner, like say, phones home to that, or how does that work? Yeah, I guess I can start and Pete, you can jump in. At a high level, I believe in Pete's demo, Pete, keep me honest here, the GitLab server that Pete was working on was probably the GitLab SAS version, right? So Pete was on GitLab SAS, GitLab.com. And what's interesting in Pete's demo, he was then connecting to a runner operator plus runner that he installed in an OpenShift environment. So you can imagine as a user or a customer that could be your own OpenShift environment. So the relationship is always, you have a GitLab server somewhere if either GitLab SAS or a GitLab server that you install yourself and you associate a GitLab server with a runner. So that's the relationship. So today, as you rightly pointed out, Michael, the runner operator and the runner is available to be installed in OpenShift. GitLab server is going to be coming soon. I believe, Pete, we are targeting that 1.1, which is our April release, so that folks that may not be able to use GitLab SAS can leverage the GitLab server in OpenShift. Yeah, that's correct. And that's something that I've been pushing for very hard. So I'm very excited to see that. But yes, you are right, Darren. So Michael, in this specific demo, it was a SAS instance of GitLab out in Internetland. And the interesting part is the OpenShift server in this instance is behind a firewall. I installed the GitLab runner on that instance of OpenShift. And the way that the runner works is it actually pulls the GitLab server, right? So it's an outbound communication to the SAS instance of GitLab to see if there's any jobs awaiting. If there is, it gets the information and runs that job. And then it was able to push that workload over to my OpenShift instance in this instance. So I guess the answer to your question is it's very configurable in the way that you want to set up your environment. As long as there's communication paths, in the federal space, sometimes there's hurdles to jump through in terms of communication paths. But it'll work SAS on-prem, however you want to set it up. Do you see that there's a different set of roles and requirements in the federal space? I mean, this may be a stupid question, but are they more on-premise due to security concerns about where their jobs are running in the federal space? Or does everyone just trust the interweb these days? So this is more of a, yeah, it's a preference things, I guess, kind of so to speak, where they're keeping it on-premise in order for them to go anywhere SAS that needs to be bed ramped in order for them to be allowed to use that service. So I'm not sitting here saying that they do not use online services or SAS services. I'm just saying from a GitLab standpoint, the majority of the deployments that we see are on-premise in the federal space. Okay, fair enough. Looks like we have another question come in here from, is it Meek310 or Meeko31? He says, I've had no luck running GitLab server on OCP without root. Goes against the NOID compliance. Will there be a light version that complies maybe? And by the way, Meeko, make sure you shoot me your contact information and when we get these shirts made, we'll shoot one out off to you. And let me know in your email if you're a large, medium, or small or whatever, so. I'm just gonna back to you. Yeah, that's a great question, Meeko. I need to double check exactly how we're developing the current version of the GitLab server for OpenShift. I believe that the NOID requirements should be in there, but I'll need to double check that. So Meeko, I'll grab your information from Michael as well and maybe I'll connect with you offline just to make sure that I answered the question accurately in terms of are we taking care of the NOID pieces? If you were interested, Meeko, we did take care of it for the runner. So the runner is compliant with all of the NOID stuff, but I'll double check for you on the server side. And if I could, one other thing I'd like to add is at GitLab, we try to be as transparent as possible. And when I say that, I'm referring to our product, for instance. You have the ability to go out to gitlab.com and actually search for the issues in which we're working on these. So you might see feature requests or enhancement requests out there. So my urge to you is go out there and do a search for any UID and see what the product or the status is. I know that we have an EPIC out there, for instance, that we are working on, which is publicly available, which you can see all the statuses of everything that's going on. So you definitely have all that information available to your fingertips. Thank you, that's a great point. I'm dropping that EPIC into the chat window if folks are interested in taking a look. Yeah, good idea. Now, what is that that you just linked in there? So basically that is actually the EPIC and actually this is a good example of how we use GitLab to collaborate on software. So this EPIC is the EPIC that's around GitLab being ready, the GitLab server being available in OpenShift, in beta, in our FlixNet 1.1 release. So Michael, you can take a look. It's completely open and transparent, but in this EPIC we describe the scope of the project and then there are a whole number of related issues and merge requests and so forth. And so this is kind of telling the world what we're actually working on, what features will actually be there in the server version of GitLab, OpenShift, et cetera, et cetera. Gotcha. Yeah, I'm actually just scanning over it right now very, very briefly. What's the issue of not requiring a root access? Meaning, does this have to be set up by someone with root? It's a deep OpenShift question. There are very specific rules in OpenShift in regards to using NuIND and that's kind of the key, that's really, it's really a Red Hat OpenShift thing in terms of the sort of the NuIND requirement. Not mean to go like too deep into it, but that's leaving it at a very high level. Okay, we've got a couple more questions here. One from Mikey, are Red Hat actions supported? I'm not sure. What are Red Hat actions actually? I'm not sure I'm familiar with Red Hat actions. Red Hat dash actions. By the way, ladies and gentlemen, welcome to our show today. This is Stump the Product Manager. My name is Mike, wait for Red Hat. So Mike, I can actually answer that. The Red Hat actions are actually GitHub actions. So I'm not sure where y'all stand with GitHub actions if there's any compatibility there. Oh, so you're talking about GitHub actions. Okay, well, no, it's definitely two different products, products in this case. I mean, GitHub actions is how GitHub has implemented CICD on the GitHub platform. So two different product streets at this point, to be quite honest. I think it's a sympathy with the answer to that. Two different products from two different companies. Exactly. But presumably customers have a mix of just about everything out there. So I might ask the question, then I don't know you tell me, but we're talking about large customers, whether it's in the federal space or financial services, presumably there's different groups within side different companies that are using different DevOps platforms. So you probably see some customers, yes or no, that have GitLab, GitHub and or others, yes? Yeah, absolutely. You're gonna find, and stepping back, that's the goal of GitHub, right? Is that if the idea is, and what we're seeing with other companies that have adopted GitLab in total, is that because you now have a single tool chain, you no longer have the need to say maintain a Jenkins or maintain something else to do your DevOps or maintain a different tool for project management. But you're right, you'll go into an existing organization today and team A might be on Jenkins, team B might be on GitHub, team C might be on something else. Absolutely right. But if you start thinking about adopting GitLab, then you can actually start thinking about getting all of those tool chains out of your organization, out of your shop and doing all of your self-development in just GitLab. Okay. We had another question come in from YouTube, wave to YouTubers. Hello. The question is from Preston Davis. Does GitLab run on GovCloud? So Darren, I guess I'll take that one. The answer is yes, we do. And not only that, we somewhat recently announced that GitLab is available in the AWS Marketplace as well. So you'll be able to provision it into GovCloud via the Marketplace. Okay. That's pretty straight cut and dried. What about this one? Are GitHub actions similar to runners? GitHub actions is GitHub's implementation of CI CD. It's similar to runners. I think they actually call their runner GitHub agent. And I think they're using the same software that Microsoft Azure is using. So they call it an agent. Whereas GitHub actions I think is what they're referring to or the technology they use to refer to their CI CD offering. So I think, yeah, but I think the more accurate sort of Apple comparison is the GitHub agent and the GitLab runner. Okay. Here's a long one. This one's also coming in from YouTube from Sebastian. Can we opt, and I'm gonna optimize in quotes, right? Can we optimize our projects, build time or runner availability for multiple projects building at the same time by deploying a GitLab runner on OpenShift? I'm gonna try to pass this question. So can we optimize our projects, build time or availability for multiple projects? I guess Sebastian, you can keep us honest here and Sebastian on YouTube. Are you basically trying to get to a state where you're only deploying a runner when you need to? If that is the core question, the answer is currently not. As Pete was showing in this demo, you would want to install your runner on OpenShift first because what's happening is the runner is pulling GitLab for an available job. You can certainly optimize your projects build times and there's certainly different strategies to do that. So I think generally speaking, yes, I think we can certainly delve into your use case a bit more and kind of tease out exactly kind of what you're trying to solve for in terms of the availability by multiple projects piece of this. Okay, Sebastian, hopefully that answers your question. And by the way, if it doesn't, we're really accessible people, like you can send me an email. Again, it's just wait at redhat.com. You want to get in touch with Darren. You want to get in touch with Pete or anybody else. Like we're really easy to work with and so don't think that this is the last chance to get any questions answered from us. Mikey wanted to know what runners are supported. Just basically, in this case, just one GitLab runner. At a really high level, you have just the one GitLab runner software itself and within the GitLab runner software binary, we support either A, multiple target deployment environments or B, multiple executor times. So in the case of OpenShift, we are leveraging our Kubernetes executor and of course we're packaging it up with the operator in terms of the install process and the management process. So it's just one runner, multiple the environments. Okay, and I'm going to continue to read the questions because the other people watching on YouTube and Facebook won't know what the question is. So we've got a couple more here. I'm going to allow Pete to pronounce this person's name. You can take a stab at that one and why don't you read that question off? It's probably up your alley. Rapscallion Reeves, I think. Is there a marketplace where I can find pre-made GitLab CI EML files for common projects, i.e. rebuilding and deploying Node.js apps? So the answer is yes, but it's not specifically in marketplace. It's actually within GitLab. So one of the things you can do. So if you're already a user of GitLab and if you're not, you can go to gitlab.com and sign up for a free account and start using it. But my suggestion there is once you go into the repo, you can opt to create a new file. And when you do that, you can opt to use a template. And from the templates we basically have I don't even know what the number is. A series of pre-made GitLab CI EML files in various languages already for you to go. So the answer is yes, from within GitLab. I'm not positive if marketplace has anything, but we do have some standard pre-canned EML files at your disposal. Okay. This one's from Oleg. I think this one's also from YouTube maybe it could be from Facebook, I'm not sure. Oleg wants to know, are you using operator SDK for building GitLab operators? What was the most difficult part of creating an operator? And actually, let me ask another question in advance of that. Is your operator built in Go or is it more of a Helm chart? So the answer is Go. And the answer is yes, we use the operator SDK for building it. In terms of what's the most difficult part, I can answer that. I personally, this is a downing, can't answer that question Oleg, but you can certainly ask that question of the developers that actually did the coding work. And so I will just drop in the chat window the link to that project. Oleg, just feel free to create an issue in there and ask that question. Hey, I'm interested in understanding what was difficult about using the operator SDK. Can you give me some pointers or what have you? And the developers will actually respond to your question. Okay. We have four minutes left and you're, Darren, your team provided me a whole bunch of questions just in case we didn't have anything to talk about so we wouldn't be sitting here saying great, well, that's really excellent. I'm not even gonna get to them. So I'm not gonna read these canned questions at all. But I did wanna ask you about what's next in the next major release of coming up for GitLab. And that ties in really well with Preston's question that just came in. For the upcoming GitLab server, will it install operators a different user than Root? And maybe you can kind of, Darren, tie that in with like what's coming in your releases, the major releases for your products. Okay, so in terms of the GitLab server itself, I'm in the product manager for GitLab server. So Preston, I wanna point you to the link that we posted earlier on that takes you to the Epic for the GitLab server on OpenShift. Go ahead and raise that question in Epic in terms of the Root requirements or any other folks that are listening in the call, the requirements around NUID and the product management team and development team working on GitLab server respond to that. Michael, in terms of the runner, what's coming in our major release, we've got a bunch of things coming in our major release just forwarding it all for the runner. Specific to OpenShift, we're doing things related to PUT cleanup and then some additional work related to managing of Root certificates. But yeah, if folks are interested in things that are happening specific on the server side, yeah, thank you, Preston. That Epic there is a place to raise those questions. The product management team will respond to them. Okay, we get time for this one last one. Sebastian has a clarifying question. I don't know, Pete, you wanna read that off? So YouTube and Facebook knows what the question is. Pete, you're on mute. You need one of our T-shirts. I was gonna say that should, yep, I was just demonstrating the usefulness of your T-shirts. So anyway, my question was referring to something like auto scaling up or down of the GitLab runners to prevent small project builds from waiting for a big project to finish building. And I'm gonna pass this to Darren because I think you know the answer to that one. Yeah, and Sebastian, the thing that we have in the flexibility as people is kinda showing as well is that you can configure the runners to solve different, you're sort of like use cases in terms of project sizes and large project versus small project. At a high level, yes, auto scaling is definitely there. You also have the additional flexibility of just being able to simply to register different runners for different types of products. So maybe you have a runner that's gonna just handle the last project builds, right? And it will handle auto scaling on your OpenShift cluster. And maybe you have a different one and that's gonna handle maybe your Node.js project and maybe it's in a separate name space or something like that. So the answer is at a high level, yes, you have auto scaling capabilities, but you also have the ability to configure the runners in a way that really addresses your use cases in terms of the type of sub-build jobs and how large and how frequent and so on. And again, if you have any questions, Sebastian, ping us at any one of those issues and we will help you kind of get going in terms of your configurations. Okay, we are out of time. I'm gonna grab the screen share here. And again, if anyone has more questions, send them to wait at redhat.com. I'll get them answered or if you guys wanna call, call Darren and Pete at their home phone. We're gonna put that up on the screen here right now. Yeah, I have mine forwarded over to Darren. Yeah, so this was your, this was the call to action slide that you got that your marketing folks sent over to me. I don't know if I go paid view, whatever. Anyways, people can be a part of their pipeline on OpenShift event that's coming up on April 29th. Thanks everyone for joining today. And Pete and Darren, thanks so much for coming here and being our victims. It was really nice to have you on. Thanks for having us. Yeah, thanks for having us. And I'll catch up with you guys. If you guys want some shirts for the GitLab folks, you know, just let me know and we can shoot some over to, we haven't made them yet. We just, we were just, we've been kind of like stalling on actually making and we just haven't got around to it. But we'll, I really think that they can be very useful. Well, as you just saw, I just, yep, definitely. Okay, well, we're done with this version of the OpenShift Commons Briefing Operator Hours. Thanks everyone for coming and we'll see you next Wednesday. Thanks. Thank you all.