 Good morning everybody and welcome to another OpenShift Commons briefing. This week we are really happy to have DJ Mutney here, a fellow Canadian from Vancouver who is the Build Engineer over at GitLab, which I don't think is in Victoria or it's not a Canadian company, it's based in the States, but we're really happy to have other Canadians with us and he's going to give us a how-to code test and deploy with GitLab on OpenShift Talk today. The way this briefing works is we give him the floor for 20-30 minutes to do a talk and the demo and walk through the tutorial or whatever it is that he's put in store for us and you can ask questions via the chat. We'll try and answer them, the good ones will read out and have DJ talk too for the sake of the recording and then we'll open up the mics as well and let people ask questions and have a dialogue at the end. I also wanted to mention that on November 7th in Seattle we're going to be in person with the OpenShift Commons, we're hosting the OpenShift Commons gathering. You can find out more details at commons.openshift.org slash gathering and that's going to be an all-day event with upstream project leaders, users, post operators of OpenShift doing a lot of updates on some of the talks that they've given over the past two years through the briefings as well as a good chance to network and meet all your peers and have time for all the special interest groups to gather and be together. So with that plug for this upcoming event I will stop and let DJ take over the mic and give us some insight into GitLab on OpenShift. So thanks DJ for being here today. Thank you. So here at GitLab we've been working together with some of you at OpenShift on creating a templated deploy of GitLab in OpenShift for the past couple months. Our target for this initial template which is actually releasing today with our release of GitLab 8.12 is the actual target is the OpenShift all-in-one VM as a developer environment. So that's what I'm going to be showing today but I'm also going to be talking about installing it in OpenShift Origin outside of the all-in-one VM and what the differences are in that case and kind of showing that showing what the difference is and on top of showing what that template is today and that deploys today we're going to then after we get that what we have today deployed we're going to get a little bit hacky and start adding in some additional components to show off some stuff that you definitely can do very very legitimately but we're going to have a little bit more fun today and add in the CI and deploy the component all in OpenShift here integrated with GitLab. So a little bit about me my name is DJ Mountney I'm a build engineer at GitLab and what build engineers at GitLab do is we're in charge of packaging and configuration for the GitLab product. So underneath there I have a little description of the pipeline of what we do and I think that's particularly interesting to this talk as it'll make it clear it'll make it clear what it is we're dealing with and what went into it for the template. So even if you in terms of my job and the other people in my team even if you abstracted away the GitLab product we're basically taking some piece of source code bundling it up using a Chef software called Omnibus which is going to pull in its dependencies and and patch it up as as devs and rpms and then one of the things we're going to do is distribute those devs and rpms to customers for install the other thing we do is we put them into cloud images like Amazon AMI images and put those in the Amazon store we also build from those same devs and rpms or specifically from the dev we build a docker image and push that to docker hub and then from that official docker image we are creating container deployment templates today we're talking about the open shift one so that's that's kind of the the pipeline of what we do and as you can see as we go through and we're talking about this open shift template it's built on top of this docker image which is built on top of our Omnibus bundled dev which is built on top of which includes the source code and the other dependencies. Just really quickly a little bit about GitLab I'm not actually going to talk that much about GitLab the product other than what you see and I'm not actually going to talk that much about GitLab the company if you have questions at the end about either one be sure to ask me for sure but my demo is actually because it's the only one VM I'm running it on my laptop and it's not going to be the fastest demo in the world and so it's going to actually take up most of the time so most of the slides that I have will just be there for going over while we're waiting for some builds to run so about GitLab it's an on-premises development collaboration tool based on Git so that's kind of its selling feature we do have free private repos in the cloud on gitlab.com and we also do a service offering on githost.io where you can pay for your own private instances that we host and manage for you but primarily what we are is this on-premise installation of a source control solution and collaboration around your source control and your software development so we're heavily based on Git and then we add in all the tools around it to help you test and deploy and iterate it comes in two editions community the free community edition and the enterprise edition which is paid licensing the community edition is open source and licensed under MIT and we release every month on the 22nd which hey that's today so a little bit about the template we're using today so we're using the OpenShift template for GitLab or maybe it's the GitLab template for OpenShift I'm not sure but it's essentially it's an OpenShift template that defines GitLab's deployment configs and it's located here at this URL and it actually is there right now but it's pointing at an older version which includes more steps but after this meeting we're going I'm going to be updating the template at that location to be what we're using here today what I was waiting on is about half an hour before this meeting we actually started pushing our tags live for 8.12 so I couldn't really update and point it at Docker images that didn't exist yet an easier way to find the template is to go to Docker Hub finding our GitLab official image and in the description there's a link to the Docker file and this file this OpenShift template is up here to our Docker file so I'm actually going to go there in a minute here but just my last slide before actually jumping into my screen sharing what is this template what is this template intended for and why am I saying that we're releasing the template today well it's because it works with GitLab 8.12 we've been working for the last few months on workaround issues we had with the persistent volumes and our requirements for for things running is root and so as of today in the 8.12 we have it working out of the box in the all-in-one dev VM so that's why we're saying it's released today and it's dependent also on the OpenShift Origin 1.3.0 release which was released a few days ago or any alpha or RC of that it works fine on today we'll be using RC1 in my all-in-one dev VM even though there has been a release of the new one already so I'll talk a little bit once once we're into the demo a little bit I'll talk about what's the differences between what we're doing and what we have to do to set it up if you're not using the all-in-one VM so just to jump over to Docker Hub to quickly point you guys at how you would actually find the image you search for GitLab or GitLab CE or GitLab EE we have these official images, Docker images and we have in the description of them we have a link to the Docker file in our Omnibus repository which the Omnibus was that piece that we used in the packaging and you can see here it lives here in this repository is a peer to our Docker file so I just wanted to show that and this is my OpenShift Origin all-in-one instance running on a local VM port and it's running 1.3.0 RC1 I was priming some of the registry here so I'll just remove this without this project it's basically a clean install of the OpenShift Origin all I've done is prime some of the Docker Hub images into the registry to speed this demo along a little bit okay so this is our OpenShift Origin instance we're going to go ahead and create a new project called GitLab and we're going to create a new project for GitLab to put our template in in order to kind of isolate the service users to this one space which isn't necessary for the all-in-one VM but we're going to as we're going to show kind of how it would work outside of the all-in-one VM as well we're going to go ahead and do it this way great I want a new project called GitLab and we'll go ahead and talk about what the differences here are between running GitLab in the all-in-one and the regular OpenShift Origin so it basically for our purposes it comes down to the security context the default security context so if we look at the any UID security context on OpenShift in the all-in-one VM it includes this system authenticated user so every authenticated system user to the all-in-one VM has access to the use any UID when when deploying containers in the case of the GitLab container because we do rely on Omnibus which is a Chef Solo server and it does expect to be able to do things like chone and chone is a root operation we do have to make sure that the GitLab user is able to run as any UID in the all-in-one VM this is already set up because of this line here in the OpenShift Origin outside of the all-in-one VM you'd have to manually add a service account ssrl to the any UID I'm going to actually even though I'm in the all-in-one VM image I'm just going to go ahead and delete that line just to make it somewhat more like a regular install if you were just installing this in the all-in-one image you wouldn't have to do this depending that I'm a cluster admin on a regular origin server I'm going to go ahead and add the default GitLab project service account to the any UID security context you do that if we go back and we look at the security context in which for them we'll see that it now has this user added and that's that's basically what you would need to do to get it working in a regular origin instance of course you could instead of using this default account you could go in and change our template to use a defined service account and you could or change go into the deployment config after it's installed and change it and create your own service account to lock it down a little bit more but for the demo this would be how we're showing it okay so um those two changes I made uh or the changes to this the security context I made you wouldn't have to normally do in the the all-in-one image what you do have to do right now is you actually have to add the template in to OpenShift so we're going to go ahead and add our um template so I've this is a checkout of that that omnibus repo that I was showing you and I'm going to add the OpenShift template go into the back in the UI I'll go into the uh increase the font here and we'll go into the GitLab project we'll add the project and you can see we have the GitLab CE application here so like I was mentioning before we're targeting the all-in-one VM for this first release and this is kind of the first release we're we're considering supported and as a result it's still missing a bunch of things one of the things that's missing is support for a GitLab EE image at the moment so that's currently not here we just have the community edition if we click on it we see it's going to include three images or deployments one of GitLab CE which is going to be our main application that we can actually increase the replicas on to scale and then we have a Redis and a Postgres image that you can only have one of in the current setup so one of the other things is as you can see there's a bit of uh config options here in the initial go the initial release but there's if you're familiar with GitLab it's certainly not all of them nor nor close to all of them so that's another thing we want to enhance going forward but this is kind of the state of it at the moment so we we're going to have to put in a hostname because I'm using the all-in-vm I'm going to use the public DNS service for IPs and and use this one and I can just ignore the rest for now and go ahead and hit create and we'll continue to overview and you can see it's created a deployment for the GitLab CE application Postgres Redis it's going to boot them up I primed some of the images for for to GitLab CE for when it is pulling it in so it won't take as long as it would normally normally it's pulling from from Docker Hub so depending on your connection and depending on how much load is on Docker Hub it can take quite a bit of time which is why I kind of pre-primed a bit if we jump into monitoring we'd see already some health probes failed that'll be fine though they'll eventually everything will eventually come up and be deployed I'll just walk through some of the the settings in the UI or some of the the objects in the UI that we've added in our template so under storage we're using persistent volume claims so we have one for Redis one for Postgres we have one for your GitLab data so that's your Git repositories your build artifacts from CI and your user uploads for images and stuff like that on comments and stuff like that so that's all stored there and then we have the GitLab CE ETC directory so this is where the config file lives so there we have a couple different ways you can configure this so as you can see you can configure a few of the options on the first click the install screen another place you can configure is using our our file system configuration file which is located on this drive so if you have access to wherever this volume claim is is persisted you could go in and change the ETC GitLab GitLab RB file to to change your configuration and just do a redeploy or you can go in and of course change it manually in your deployment using environment variables so we have this Omnibus config environment variable that includes basically what's in what you can put in that RB file at the moment what's in here at the moment is actually just the config necessary to move the storage directories to those persistent volumes and make use of the Redis and Postgres the only other thing other than that is this password that we that I ignored to put in and your actual external URL those are the only two things separate from kind of just moving directories around for this template as far as images we have the GitLab CE image which is pulling using our release candidate later today I'll switch it over to using our actual release and also a Redis image which is using the official Redis image on GitHub and then the Postgres image is actually coming from OpenShift itself it's using OpenShift's Postgres image and there's not too much more to show in terms of objects created with the template we have our Redis and our Postgres already up and running the GitLab CE the image should have been pulled and installed and now what it's doing is probably populating the database if we go into the logs it's kind of running our reconfiguring, configuring the first time setup subsequent setups and installs will be faster than this this first one takes a bit of time though so while that's running I'm going to jump back to my slides and kind of walk through what we just did not super exciting but we created a new project we checked out the differences between the all-in-one VM and the OpenShift origin in terms of what it means to GitLab at least and we added in the case of using origin we added a security context in a UID so we could run as root and we went ahead and added the template in and this is the step that we're on we created the project specified the host name and we're just waiting for it to set up and deploy so it's now up and running and it should be available so we also attached a route to just the CE deployment so up and running should be available at this URL for me and it is before we do too much I'm going to go ahead and scale it to two just to show that it can be scaled to two I'm not going to really wait for it though I'm going to go ahead and show off GitLab a little bit probably most some of you at least have already seen it so this will be probably boring but we're doing a CI CD demo so that's what you get because I didn't specify a root password in the click the install section I get to specify one now for the root user and I'm going to go ahead and sign in as the root user okay welcome to GitLab I'm going to quickly walk through other config options the root user is logged in as an admin user so I can go to the admin area and go over to oh we can see the new the new release is already available anyways we can go over to the settings in the this is the admin area and go into settings and this is where a bunch of the rest of our settings are located that are stored in the database that you don't have to change on the file system or in environment variables so there's a bunch of additional settings in here that I won't really talk too much about just for fun we'll turn off we've signed in we want to sign up disabled so no one else can sign up for now not that it matters because it's just on my local machine a bunch of different settings that don't require because they're stored in the database don't require you to change anything in your file system so if we jump back to the project we're gonna go ahead and create a project in GitLab so normally your workflow would probably be to create teams and user accounts and add teams and then what we call them groups actually instead of teams and create your projects in in those groups I'm just going to use the root name space for demo and we're just going to call it website so once you created it you'd be able to to push your your Git repository to to GitLab I'm going to actually pull in an existing repository and I'm going to actually take in terms of website I'm actually going to take the public source code for abote.gitlab.com website and we're going to we're going to deploy that our own version of that increase the font here we're going to make it public for the sake of the deploy step later on we're going to keep this public you can set it up to to check out using username and password as well even in the deployment but for the demo we're going to keep it simple and plus this website was already public so it's going to go ahead and import the this repository is actually like half a almost half a gig in size so in retrospect when I was doing said running through this demo a few times I realized maybe it wasn't the best one to show because it's going to take a while like everything's going to take a while unfortunately but that's what I ended up doing so once this import is done and we'll see a few more options but you already see some features of github we see the activity we see we have an activity feed we have pipelines which is the CR integrated CI solution we have issue tracker wiki and snippets once this import is done we're going to see our repository tab which is our file browser and also merge request tab which is the same as github pull requests essentially but for for code viewing and merging into your mainlines so we're going to let this run and effectively like this this is this is the template that we've been working on and this is git lab and this is git lab running and oh it finished already it's actually faster than I thought maybe get lab done oh i got faster um but um so this is the the template that we've been working on and this is git lab and now we can we can clone and we can create merge requests and all this other stuff but for today's demo we're going to now jump jump away from just this template and and and show kind of stuff that isn't available yet but are just kind of like future aspirations and things i'm excited about and things you can do already with Jenkins for for example so just to talk about how you set up CI with Jenkins i'm not actually going to set up CI with Jenkins i'm going to set up CI with our own git lab CI but we'll talk we'll jump back to the slides and talk about if you were to set up CI with Jenkins so this is the point that we're at it's integration you would uh first you would install Jenkins so it's actually as as you guys all know probably it's very easy to install here in OpenShift but uh we also need for git lab integration we need the git lab plugin which is located here for Jenkins so you'd have to make sure that that plugin is enabled and also the credentials plugin comes in pretty handy as well so the kind of the general steps that we're not actually going to do but you would have to do for Jenkins is you need to install Jenkins of course you need to create a new git lab user for Jenkins in git lab because you're going to use their if you want to use private repositories instead of the public ones you're going to use their username and password and the credentials plugin and also their private token for integrating with the plugin you would then set the git lab server host name and the Jenkins user's private token in the Jenkins management page in the Jenkins management page there's an after you have the git lab plugin there's this section for git lab you would then when you're building your Jenkins job you would configure the git lab plugin it's now a build option in the the Jenkins job and you would basically you point it at your your repo using the the git URL and you use the credential plugin to provide it with login if it's not a public repo and while you're setting up that plugin it'll actually give you a callback URL to use in the git lab webhooks section of the product so we're actually what we will show from this is the parts that also relate to ci so ci kind of has the the first step we also need to install something and then has the last step we also need to set up well we don't actually need to set up the webhooks for ci we're going to set up webhooks for the deployment part in the source to image which is what i'm going to be using for building and deploying in today's demo so using git lab ci so git lab ci what is git lab ci it's it's ci that's tightly integrated into git lab it does in addition so it's the the api side of it is already in that git lab docker image that we loaded up it was under that pipelines in the ui was under the pipelines tab in your project it does require that you register these runners to execute ci scripts these runners are what we're going to load up in uh open shift our runners and the runner we're using today is our official docker image for our git lab ci runners runners also have support for managing kubernetes pods and that kubernetes support releases today with 812 and our new git lab runner but we don't have an open shift template that works with it quite yet i was working last night on trying to get one up but i just couldn't get it up for the demo so today unfortunately we're going to do one that isn't using today's release but instead we're going to be using a docker and docker version of our ci template using a very hacky template that i i whipped up and we're going to show it in open shift and it's it's totally working project uh work in progress i will push it up to our omnibus repo uh so you guys can take a look and laugh at me and uh and cringe at the horribleness of it but the the end result today will work for our demo we won't be cringing we'll be saying thank you it's it's it's really yeah it's it's it kind of shows definitely what i think everyone wants to have happened with with the git lab ci or if we want git lab ci in open shift that'd be really awesome and with the kubernetes support we're we're going to get it there um it just today isn't today specifically isn't the day unfortunately when you might it might be the day for somebody because the support is there it's just uh not the day for me when you get there we'll do a blog post about it let everybody know so yeah that'd be great okay i'm going to jump back to um uh jump back to my website and we're going to set up ci so because i did a clone of um this was a clone from git lab um and this is our actual website it actually already has a ci configuration so we're just going to click on that link and this is our git lab ci yaml file um we're not going to use all this today um because we're going to leave the build and the deploy up to the source to image stuff so we're really only going to do the linter in terms of ci our ci yaml's include a docker image so this looks like a big scary docker image i actually have it open over here so this is the docker file for that image it's actually just a ruby two three slim that is installing a couple packages and then cleaning up after them and then setting the encoding environment in terms of utf encoding um and the reason we have this in an image of course is to so these steps don't have to happen during the uh di um run so that they've already been done and they're already in an image that can just be pulled down and cached um so i'm going to close that and uh this is our official website close that and this is my deploy okay so i'm going to head and edit this file we're in master right now i'm just going to drop out um the deploy step we're back on we're going to drop the build step we're going to drop this tag because we're only going to set up one ci runner this tag lets you determine which uh runners it's going to run on so this one's specific to make sure you run on a docker runner uh we're not going to tag our runners today so we're going to drop the tag we're going to leave the stage build but we're going to actually drop this build so this is this is going to be the template we use today we're going to include the cache because after the first run it's going to make um our subsequent runs a lot faster because it's going to basically cache the the ruby gems and allow us to just be running this command on each uh test run unless we change the gems so i'm going to go ahead and commit that and um go on over to the main project page again we can see there's a pending build for our new commit and um it's pending because there's uh the build is stuck check runners well if we go over this is the project settings over here um if we go over to runners we can see that it tells us how to set up a new runner um but we don't actually have any runners currently so we're going to add add some runners we're going to add them to open shifts so jump back over to our command line and so we're going to use uh my hacky template um my hacky template is using docker and docker and as a result i'm going to have to throw uh from the the container in privilege mode and uh just to get it uh easily set up i i'm actually using a service account that already exists unless the deployer service account and then adding that service account um to uh the privileged security context so let's go ahead and uh add it to the privileged security complex context so it's the employer account it's both that all right okay so we've added the service account to where it needs to be to run a privileged container so like i said like i said the part of the demo where we actually showed what we're releasing today and supported is is is done we showed GitLab now we're showing the hacky stuff um that i just i didn't want to set up Jenkins so i instead set up GitLab CI so we're gonna create uh from new file and i have it called my CI template so if we go back into our GitLab project and we're gonna add it to the project i now have a GitLab runner it needs access to the GitLab instance i we have ours using that the public DNS name server i don't want to overload that name server with requests from my machine so i'm actually being that this is deployed in the cluster i'm going to go ahead and use um uh the cluster's DNS name port so it was in the GitLab project service cluster local cluster oh and it's slash ci slash ci if you if we go over to the runner's page we can see it was slash ci for communicating and then we need a ci token registration token and that's this guy right here i'm gonna copy him over and then i have volume sizes for bill volumes and cash volumes go ahead and create that and it'll create a new um runner and booted up and because i had this was another image i had pre-seeded i booted up pretty quick and if we look in it um it already registered the runner which we can if we go back to our runner's page and we refresh we can see it's registered the runner and it's already grabbed that first build that we ran um so we can go over to our our pipelines we can see our build is now running we're clicking it we can go into the specific lint build and we can see its current status so this first run is going to be um it's going to take a little while because it's going to have to pull it in this registry image which isn't going to actually be the bulk of the time it's going to spend bulk of time doing the bundle install but this is going to cache those and so our next builds are going to be a lot faster in terms of ci so while that's running this is this is kind of so far we've kind of followed a nice a nice flow but now things are getting a little bit slow we're going to start jumping all over the place so hopefully after i finished jumping all over the place in the demo i can quickly run through the slides to kind of put it back in order for you and and i apologize uh but while this is running we're going to go ahead and set up what the deploy would look like on the um open shift side so we're going to use the sourced image uh stuff so we're going to um copy the git url for the website project we'll go back to our console because we used we're using the neu id privileges for this instance and we're pretending it's not an all-in-one vm we're going to go ahead and create a new project so that our our website deployment isn't getting any of that enhanced privileges um and our website is using ruby so we're going to use the ruby 2 3 builder that's already comes with uh open shift i'm just going to call it website once again because this is in the cluster we're not going to quite use the url um that it gave us because i'm using the the public domain name server provided by uh uh we can't um so instead i'm going to use this one which is our one for our cluster domain name for this one i'm going to go ahead and show advanced we're going to make sure it only deploys the master branch um we're going to create a route for the application called website and we're going to put it on the public dns and we're going to make sure that we are configuring um build triggers and other than i'm going to keep this um the same and go ahead and hit create so when you hit create it shows you the nice um build trigger web hook trigger url for uh git hub um for git lab we need to use the generic trigger but the only differences are these last two sections this secret and the uh last path we're going to go ahead and copy it we're going to go back to uh to git lab which is still running that build uh we're going to we're in the project and we're going to set up uh webbooks for this project so we're going to enter the url um and we need to basically replace the secret and this last uh last path here so um one way i've found to find it from the ui of course you could find it just by dumping the the build object on um on the command line but if we go over into the ui we can see there's this build running for website and then there's a deployment called website as well um but we're going to go in and look at the edit for the build and we see it does have a generic webhook set up here um and it does have a different secret we're going to go ahead and copy that get in here and we're only going to trigger this on build events we don't have to specify a secret token because it's already there's already one included in the url and we're going to disable SSL verification because i'm using a self sign certificate and normally in a real setup you would also hit test at this point but that would trigger an extra build so i'm just going to assume it works and we're going to see later when we start making changes whether it works or not um so we're going to go back here uh it's currently building our website installing the bundle it's checked it out it's synced it it's going to spend some time installing this is going to take a while um the one thing we do have to change specifically for our website um the deployment that got automatically set up here isn't quite enough to get ours our our particular website working it's very close though um the only thing it's missing is uh and some environment variables to get it into english utf8 encoding um i just have a copy of the environment variables here that'll get it going so before it even gets to the point of running this let me go ahead and edit it so that when it builds when it deploys it'll it'll go live so still running that first build um we go back to the git lab project uh we're still running our ci test sorry my machine isn't the fastest thing in the world we'll just check to see how far it's gotten oh not very far at all that's unfortunate it's running extra slow we're going to go ahead and blaze ahead to um because this is just the build for the master branch we're going to go ahead and show the change show what happens when we do a change um so i'm going to go ahead and open a new terminal and clone this on the command line and we're going to start a new merge request so even though it's like almost half a gig inside locally um local so it's not going to take too long to clone while you're doing that there was one question um so far um how do you handle the persistent storage when you scale up git lab and save that till later or you want to yeah i can answer right now so the persistent storage when you scale up so um it uses the same persistent storage so we specifically um separated the storage out so that uh essentially the instance-based config files in terms of that's in terms of what happens when it first when an instance first boots up in config is it's nginx and um it's unicorn workers and the rest of the things to run the application those are not persisted but things like the git repos were persisted and things like the um your build artifacts and your uploads and stuff like that were persisted so when you increase the um the instances it ends up pointing at just the same um file storage for your repos and your builds but uses other than it doesn't persist the rest of the instances running like pids or anything like that um so it basically just ends up bringing up multiple of the rails application all pointing at the same um um nfs git repositories or however you set up your persistent storage um and so you can you can scale those application servers up uh we we kind of do the same thing except outside of open shift on gitlab.com we have kind of like 20 um of these gitlab application servers that are running that are just all attached to um the same storage or or the same storage provider and um uh then we have our database and our redis uh separate uh as well so it's set up it's designed to work the same way uh in open shift even though even though right now the target is the all-in-one VM we we were kind of wanting the data to be uh set in a way that would be the same as what we want in the future so we can keep upgrading it without having to shift things around so finish cloning I'm gonna jump into the website I'm going to handle install it so I can use it locally um we'll jump back to our to our instance to see where it is just kind of check it on the status of things so in our ci instance we're still checking out and installing gems as well um luckily for the ci build all of these guys will be cached so our next build won't have to to use them or won't have to rebuild them unfortunately I didn't spend too much time monkeying with the source image stuff so the uh the build on this side um will have to you've just given away one of our demo tricks is to always do it first these ones so I'm gonna probably on my command line it's managed I already had these bundled on my command line as well so we're gonna go ahead and add a new so this is this is our this project is our gitlab website and I'm gonna go ahead and add a new blog post to it which we have a a big task for when I was doing this demo before I usually had done the clone before I had changed the gitlab ci image so I kept on pushing this new branch up and it not running ci so this time I did it properly and it uh psyched me out so when I create a new post I'm gonna edit the post I'm not gonna take it too fancy I'm just gonna push it up here and we're done with the file system part of it um so it's gonna push up a new branch so this is our initial master uh run of the ci which uh completed successfully um we're gonna go back to the command line and once it pushes it up it's gonna actually give me a link for creating a merge request which I'm going to use you can also create it through the UI find it um location for creating it so I'm gonna submit that as a new merge request I think we see uh ci build is already running for it um we can see our changes and and comment on them and get them reviewed uh so we can do the details for the running build my poor my poor computer is a little slow so while you're you're waiting for that I'm gonna ask another question um so one of the folks on the call so just ask um why do you keep saying this is targeting the all-in-one as he understands you if nfs storage or any other concurrent read write file system provider is available what would prevent it from running on any origin or open shift enterprise cluster on prem and or on cloud yeah so it's it's more just uh an excuse to say why some of the config is missing um so certainly like this is this is a actual install of of git lab using our official image so if you do go into the file system and you edit the config or you go in and you want to edit your deployment config or you want to add things built on top of our template it's it's totally all there and ready and and that's fine it's more just like explaining what's missing from the template um so the the build itself the way it runs that's that's fine it's it's it's fine you do have to be a cluster admin to add the neu id to um to the build um but as long as you can do that it will run in um in uh open shift origin um so it's it's really just uh excuse for um why the template is itself is so lacking in in configuration at the moment that's all right we'll get we'll get it up there um so it's also um might be worth sharing um what the process was that you went through for working with red hat to get this working and and who you worked with and um how that was so like i know you've had a lot of interactions with red hats and so you know other comments was what was your what was the process like to get all this yeah so essentially um we started with the all-in-one vm as well it seemed like that or was um that was kind of the initial uh desire was let's see it working in the all-in-one vm and then move on to the other stuff uh so we worked with um uh steve and uh i'm gonna mispronounce his name it's either horie or george i'm not sure um yeah uh so uh we've been working with them uh horie essentially created the initial template for us um and then we've been uh modifying it and then uh he created an initial basic template based on um our image uh and then we've been modifying it and getting him to review it um um and provide feedback on it so it's been a back and forth uh in terms of that and that's that's basically how it's been so far all right don't go ahead and accept this merge uh merge request uh it'll merge into master it'll kick off additional builds um and hopefully at least maybe even the first build will have finished in uh open shift we go look at this was the first build oh it didn't even finish yet that's okay well just what we'll do is we'll we'll only show the end output of the first build and you can just imagine the the other ones we're good at imagining things when live demos are going on so yeah you're coming up on the end of an hour so i just want to that's why i've been poking these questions and other people have questions type them into the chat and um continue on dj yeah sure i'll just jump back to my my slides so we did we're doing the deploy in this demo using the source image so we created the open shift app um we created a ruby app for um for our website and pulled from our GitLab repository we enabled the generic get trigger and we we plugged that trigger into GitLab's web hooks so kind of like what's next for the integration we need docs uh so definitely need to get the docs up there um one thing also is get ssh support right now you would have saw me only cloning over at hgdp um we need to expose the ssh port externally i understand there's a change to the uh the public uh router that went into uh to open shift that will allow us to do that we just haven't made use of it yet um that's a funny way to spell expose but expose more of the config options uh specifically uh email is one that's missing from the um from the one click installer uh adding smtp we want to add the GitLab e-images um we want to build a template around our our kubernetes uh c i runner so we are our kubernetes we have documentation already on on using kubernetes and setting up our runners to use it and setting up as a privileged um runner uh but they don't currently work out of like this template itself doesn't work out of the box if you just plug it into open shift we need to to do some investigation on getting that working um it'd be fun to do deployments from the runner uh and a clearly defined backup restore procedure right now you can because it's the same um install as as everything else you can go into those uh can there are images and run the backups um and the backups are stored onto that persisted um storage um but you actually have to like uh go into the terminal to the machine to to manage that stuff uh and then we also GitLab has integrated container registry that we have disabled right now i have a question mark after this one because it's likely not needed because often you're going to have a container registry already in uh open shift but uh just threw it in there because i'm not sure there maybe there's a use case for it in open shift uh with GitLab or maybe there's not um so just to jump back to our push was successful jump back to overview um our website is up it's running more builds basically for each push i did um and and the merge itself we're gonna ignore those builds and just look at the website the pretty website and see that yes it did deploy and we'll just buy a bigger machine next time and a real cluster and do it live yeah i actually i actually i i have a cluster setup but it's it's not on uh one three and i uh i wanted to show one three instead of showing all the extra steps that you'd have to do to get it working on the older cluster and i didn't have time to upgrade my cluster unfortunately but because the website running yeah releases happen so you know things happen and you know it's it's been great so this is a wonderful overview and lots of detail okay so that's i'm sorry it was so slow that was it for the demo if we can fit in any other questions let's do it put up your last q and a slide and or your last your final slide and we'll do that um i'm actually not seeing any questions i for he has joined us the gentleman from red hat who gave you a hand on some of that i've unmuted him and to see if he has any other things to add in um but if you could also tell people how to get a hold of you dj or or where the right place is to um reach out at gitlab um if people want more information that would be a great thing too yeah so my email is dj at gitlab.com um and the the repository that i monitor uh is the omnibus repository uh so if you have any issues with the template um would you have a issue tracker on that omnibus repository which was linked to at the beginning of the slides and linked to from our um docker image on docker hub so any issues you have uh feel free to put there or hey do you have anything to add to that no i mean it's been a great experience working with gitlab guys and i hope that people start using more gitlab and the template that they are creating and the technology that they are they are doing which is great and they help us make it better all right well i can see a number of participants on the other commons members who are on the the call here so i'm guessing that there'll be um a lot more use of gitlab's after this demo and we will be posting a recording of this and i will make dj send me his slides um as well so that you don't have to type in everything that he was typing in and can steal from that um and that should be up in a day or two on the blog openshift.com site and on the openshift youtube channel um and please um also if you have questions post them on the openshift commons mailing list and um we'll get dj to answer them there so everybody can see them um and we will be back again next week um with another openshift commons briefing and again i i will do a slight pitch for um if you're up for doing the commons briefings in person um november 7th we'll all be gathering in seattle at the openshift commons gathering you can register today um it is uh a prequel to kukon and kao dative com co-located at the seattle charitain um and the address to find that is commons.openshift.org slash gathering and if you like what you've seen in the briefings you'll love seeing everybody in person and getting to drink a beer or have lunch with them and um pepper them with questions too so um we're hoping dj and some of the git lab folks will be there and we'll get your questions answered there in person so once again thank you for joining us at this openshift commons briefing and thanks dj for doing such an awesome job showing off openshift and working with us on getting this integration up and running