 All right everyone it is 11 a.m. here on the east coast which brings us time for the functional group update I'd like to thank everybody for coming this FGU will be ran by all members of the built team that are present today I'll be covering some of the cloud native container works that I've been working on DJ will be handling some changes to the upcoming config and roles behaviors that are being introduced with GitLab 10.0 as an omnibus package Josh will be covering some installation improvements with what we've done to ease configuration in the SSL and Ian will be covering postgres HA and the upcoming changes with new versions of postgres that are coming along So I've been working lately on the cloud native containers. Okay are This has to do with creating a Docker image chart per component of the GitLab services It's being worked on at for helm.gitlab.io. This is different than our existing helm charts Our existing helm charts are used to actually deploy the omnibus container and related services However, we're looking to actually separate every role and concern into its own container to allow better maintenance and rolling forward This is a specific pathway away from our monolithic container allowing us to use Preferably all upstream containers where possible for any service that's not directly related to our code Right now we have the standalone registry that is using the upstream registry container for Docker distribution There's very solid progress there. However, there is some final testing and tweaking that needs to be done to ensure It works on all public clouds Next up is the standalone sidekick container Which is going to be an interesting feat because of the requirements that it has and the number of integrations that it has throughout all of the GitLab services. I Want to note that this is a long-term set of OKRs and that this will be something that is not completely production ready until 2018 as we continue to work on this and ensure that our Customers that are using it with GitLab EE have completely tested Rock solid behaviors before we call it completely good We will be working with parts of this however in the meantime as we make each component 100% ready. We will be getting transitioning those into staging and onto production Yeah, so some changes we've made over the past couple weeks to the top level config One of the things we added right around the time The last functional group update was a change to how you can nest Your config in GitLab Rb So we've changed it so that after a certain nesting level previously you'd have to use open up an object and instead of using the keyed style Reference you'd have to reference it You'd have to create a new object and fill it in and that was causing a lot of confusion It wasn't clear even to us on the team We didn't always remember at what level you had to do this switch from one syntax to the other And so we made a change that went into a 9.5 that allowed you to use the full syntax all the way down So that's a very apparent on something like LDAP integration in GitLab Rb Where often in the GitLab Rb opens up into this big object You could then switch to you can now switch it to be kind of the same Syntax as all the rest of the config where you have just a line for each option We've also been making a bunch of changes internally to make maintenance easier based around the top level config objects we have So we've added in this idea of services of declared services in our code So that's by services. I mean things like workhorse and GitLab pages and nginx and all that stuff is separated as A service object and that they are grouped into various areas. So Redis has several services All Prometheus has several services and exporters and those groups can be enabled and disabled within our codes that makes things a little bit easier when we go to Make roles and Disable services so that we we don't have to keep the code doesn't have to know the specific services that need to be disabled that we can just reference That we want to disable this group of services and later on we can add in more services to those groups and it's less likely that we'll miss it somewhere in our various configurations So that's been a problem that we've been running into When we've added services and we have this documentation on how to set up like an HA node and it says all these different things you have to turn off But since that documentation was there we've you know added additional services So we've made changes there to make it easier for us to manage that those those changes aren't exposed to the users yet nothing's changed there As far as users are concerned at the moment We've rewritten how we do our top level Configuration and how we declare services in our code. So I have a link to the docs. That's one of the Most common things in omnibus that the other the other teams around get lab come in and add is when they need to add a new service So we've kind of produced the duplication of the areas where they need to add Add code to get that new service config to work and added some docs around how to do it And then we've introduced We've expanded our idea of roles in The omnibus project to encompass something called the default role. So previously when you install GitLab We have a bunch of services enabled by default. We've now disabled them all by default in our code But we've now created a default role that's enabled by default that goes and enables them as you run reconfigure So this is another thing where nothing has changed as far as users are concerned. There's no user facing change at the moment But inside Omnibus things have changed quite drastically In terms of how we look at our services that are enabled and how we deal with them and how we'll be maintaining things going forward without And adding new services without forgetting about the old ones and adding new roles So those are all in use with GitLab 10.0 And then on the next slide the upcoming role changes Going in that will be going to the next couple of releases have to do with then exposing the benefits of these changes to users in the GitLab Barbie So we'll be allowing users to set the role or list of roles for your GitLab server kind of at the top of your GitLab Barbie At the moment you have to go through and kind of like find the role you want say it's a reticent no role and enable and flip it to true Well instead just beginning giving you the option to list the type of roles that your GitLab instance is this is largely for GitLab HA setups And we'll be doing a lot of focus around documenting these different roles One of the things we are doing is seeking looking for different opinions on on how to declare role specific configuration And so I've linked an issue there for a discussion around how we might be doing that in the future and how we might Change the declaration of your different settings in GitLab Barbie for different roles So that's kind of an exploratory phase at the moment And then moving on to some of the things that have just recently gone in for the 10.0 release that have been worked on by Marne We've dropped the old data dirr config option so this is from about a year ago we switched this Git data dirr config option for controlling where your Git data stored on the file system We switched it to being called Git data dirrs and it has a new format so the old format is now no longer supported and we'll throw an error in GitLab 10.0 So again the GitLab GitHTB server config has been removed so that's what GitLab Workhorse used to be called like two years ago So there was a config option called GitLab GitHTB server that of course over the years has been moved to be the GitLab Workhorse config So the old name has been removed and then we've also dropped TLS version one from our default accepted protocols And then we've also dropped Nginx inbound traffic For users who need it they can still add back the option of supporting it but it's no longer turned on by default And then finally we recently added a code of conduct to our contributing page on the GitLab Omnibus project That's all I'm going to talk about over to Joshua for installation improvements Awesome Thanks, David So we got some exciting things actually coming here with 10.0 We're doing a lot of cleanups, removing a lot of old cruft from the Omnibus package to make it easier for everyone going forward And I just saw earlier also working on some key future projects there with the client containers so all really exciting Other cool things we're doing here is also focusing on the current installation method of course which is Omnibus for most users And we've been working to make it easier to install with fewer potential bumps in the road So one really exciting feature we have in 10.0 that was added was Maran's really good idea was to allow you to pass or set the GitLab URL on the AppGet install command So you can see the command there And what this does is really allows us to skip the next two steps So before if you simply did the AppGet install you'd have to then go in edit GitLab.rb set the external URL And then run GitLab CTL reconfigure and that'll then of course apply the URL and reconfigure and start everything So you don't have to do that anymore if you actually specify it on the command line there So a nice improvement there for our users and our installation process is now reduced to three steps You install dependencies, you add the package repo and you install GitLab And after you install GitLab, GitLab is then reachable on the URL of course after we go through and start everything So really cool stuff there The one limitation is that it only works on HGP sites today However if we go to our next slide you'll see in 10.1 we're looking to address that So in 10.1 we're going to let you do the same installation command but you cannot specify HGPS And we'll go ahead and work with Let's Encrypt and retrieve these certificates for installation As long as of course it is publicly reachable which is how Let's Encrypt uses a rather validates that you have proper control of the domain So some cool stuff there we're coming in 10.1 and should really help address sort of the getting started process And testing with SSL as a lot of our newer features do depend on it For example, trying to work with the GitLab registry without having SSL turned on can be painful So this is a great improvement there The question I saw come in on renewals so we'll be adding a GitLab CTL Renewed command Well not exactly that but a Renewed command and GitLab CTL Just because that requires root access to go in and write the engine next certificates So it won't be done completely automatic because you don't have something that kind of runs over time like that that has root access However you will be able to renew them from the GitLab CTL command So obviously the key benefits here really is faster and easier installations with fewer potential potholes Configuring SSL with engine next wasn't really difficult but it also wasn't super easy straightforward You had to move files into certain locations, you had to add the GitLab RB, you had to potentially tweak some other settings depending on how your configuration was set up So again this streamlines that whole process And if you still do want to bring your own certificates and you don't want to use Let's Encrypt You of course still have all the menu configuration possibilities in Omnibus to take over and still support you So with that we can I think pass it on over to Ian and talk about all the awesome stuff coming with Postgres HA which is super exciting Thanks Josh So the last field group functional group update sorry that we had with the build team was we had just released the HA support but manual failover And that manual failover process was still somewhat painful, better than the alternative of no failover process but not perfect So with 9.5 we released the beta version of automated failover using console RepMGR and PG Bouncer We've been pounding on that, it's running and staging, we haven't found anything to run screaming from So with 10.0 we are going to no longer consider it a beta product, we are going to consider it released and supported And I know there have been some people who have been really anxious including customers as well as their production team to take advantage of that So we're excited that this is ready to go, it's been a challenging thing to do but it's cool, it's great It's pretty neat to watch it over if you knock out a database and just watch everything kind of kick in and pick a new master and then tell the application to kind of Move over and start talking to that, it's pretty neat to watch so we're happy with that and we're really excited that that is finally going to be going out the door And other people are going to get to play around with this And then also the next big step is Postgres 9.2 is no longer going to be bundled with Omnibus As of this month it has reached end of life so we should not be shipping a product that is end of life 9.6 has been available since I think November last year was the first time we bundled 9.6 in there And as of the GitLab 9.0 release we were forcing 9.6 by the fall and upgrading people unless they specifically opted out So it's time, if you're not on 9.6 already then you've been kind of dragging your feet a little too long So if anybody tries to install GitLab 10.0 with that they're still running Postgres 9.2 Then that is going to error, it won't kill their GitLab installation It'll still be running on the older version but they will need to first upgrade to Postgres 9.6 in order to upgrade to GitLab 10.0 And the good news on that is that we will move our versioning apart a little bit So we'll no longer be really confusing to be talking about GitLab and Postgres at the same time and have to worry about 9.x of which GitLab or Postgres Unfortunately that is short-lived because by the end of the year Postgres 10.0 is due to be released So then we'll have the confusing versioning again But there are some good cool things in that I encourage everybody to look at the release notes I believe the database team is very excited to get that rolled out And we certainly can't be supporting three versions of Postgres in the package at all So we're getting 9.2 out in time to roll 10.0 out when it is released Just for using the Postgres bundled version, or I know that's bundled version of Postgres right So if you're using external versions of Postgres best one effective Not immediately. I believe there is some functionality that the database team wants to take advantage of that they can't if people are still running 9.2 So I can't speak on when that will be removed from GitLab But currently it will just be affecting people who are using the bundled Postgres version So I think that's it for me and we are on to questions No questions? Yeah I'm not seeing any questions in there so if anybody has any jump them in real quick Otherwise we're going to give you back 13 minutes of your day Alright well thanks everyone for coming We will see you in the team call