 Okay, it's a full hour at my location, so I think we can start. Welcome to the Functional Group Update for the building. I don't really want to use Yob's terms, like everything is amazing, everything is awesome, but I'm really excited to present some of our built OKRs, and I want to like guide you to what we are doing right now and what we will be doing with our OKRs, and trust me, you're in a really good position to take a really great ride with us. So, let's get started. Our first OKR for the quarter that just started is deliver PGHA in omnibus and Terraform to enable HA. So, basically, we want to finally get rid of the task that Ian has been working on for months and months where the target has been moved multiple times, and just as we were reaching out to finish everything, we started everything from scratch, but I already announced some things that we did ship, like PGBouncer, which landed in 9.2, but I think crucial intersection for us was when we realized that we had a lot of things overlapping with the production team. Our database on gitlab.com is running, which is fine, but we wanted to run with the package and with the support from the package, and while the production team was thinking about how they can actually rebuild the current situation, we realized, hey, why not just work together on this? And this sped us up unbelievably. We got to test the new library that we are going to ship as part of our PGHA solution. We got to test it on staging with Ian and Jason. They had first successful runs there. They also tried some automated failovers in there with the custom package, which is, again, quite brilliant. And to make sure that we have a situation where we could ship this or test this in production, we shipped RepMGR, which is that library that we'll be shipping. To everyone as part of PGHA, we shipped it in 9.3 without user-facing configuration, which meant that we can just place things all over the file system if necessary and run our things manually without introducing anything to the end user. So that actually also allowed us to do some other manual tests on staging with the configuration that is going to be shipped to the users. And I'm extremely excited to say that we have a merge request that is currently working progress, but which will land in 9.4 and we will be able to in 9.4 say to our customers, you have PGHA out of the package. You'll have to do some manual failovers. If you need to do a failover, you'll have to do a manual one, not automatic just yet, but this allowed us to at least also write the documentation on how you can actually do it. And we will be introducing that on gitlab.com. So amazing work by Ian and Jason, like big times up. Because we kind of cheated when we were writing our OKRs, we decided let's, because we are going to ship PGHA and we are going to reach our OKR basically within couple of weeks from defining it. Let's move on and finish the rest and do the complete PGHA, sorry, HA solution out of the package. We are going to work on creating configuration, easier configuration for everyone for the gitlab application itself. So you wouldn't have to configure too many things. We'll try to configure as many things as possible for you. And for that, we are going to address some of the technical debt issues that we've been having and we are going to make sure that the role-based configuration is, yeah, I wrote here first class citizens, I guess I was a bit inspired, but it's going to be on par with the rest of our configuration. As part of this work also, we decided we are not going to complicate things a lot by introducing licensing for HA. There is this huge discussion that you can actually read in the issue I linked there. So we are instead of trying to ask our users to complicate their setup and introduce a license which can create a chicken and egg situation, we are going to focus on getting this into a gitlab UI, which will give the users a place where they can actually check what kind of license they need. And hopefully ultimately somewhere down the road, maybe even some monitoring to Prometheus. So that license can actually just be added in one place and that is from the interface of our admin UI. Further on, second build OKR, deliver service specific Docker images and Helm charts usable for gitlab.com. When we were writing this OKR, we noticed that production has a very similar one which stated something to the extent of use Helm charts on gitlab.com. For anyone who ever peaked into our infrastructure, they would probably be able to tell you how difficult the task is to go from a current situation to running kubernetes on gitlab.com. So we decided, again, why not work together? So we are actually working together where we are starting with the container registry. The idea is very simple. We are going to try and improve the current situation where we are going to split all of the services onto separate nodes by using our omnibus package. So get into a state where we can, with certainty, say the application is working correctly with the current situation that we have. We have staging that is actually working progress when it comes to registry. And yesterday or today I'm not really sure which day it is anymore. We actually have registry completely separate running on staging, which means that the gitlab application is running without registry on the same node, which is the current case for gitlab.com. That also allows us to, when we are confident and when we introduce this on gitlab.com, we can go back and rewrite this into a separate chart, so that we could then test in staging again and just switch out the services when we are ready for production. That would also allow the built-in to take our time and make sure that we have charts that are foolproof, that are production tested before we even release it to our users. Another OKR of ours is Simplifying HTTPS Configuration. It says in OmniBus and Helm, for Rails app, container registry and pages, consider Let's Encrypt. In Helm, we are already using Let's Encrypt. The current charts that we have are already using Let's Encrypt. They have several limitations and those limitations are basically everything that is stated in the issue I linked, which says support in OmniBus, gitlab is highly requested. Obviously, our community is highly excited about this feature. Anyone who knows me knows that I'm not at all because I think Let's Encrypt is not production ready, but during our installation call that the SIDS did two weeks ago, we got to a point where I saw that we have a very good opening to improve the situation for everyone using the package without actually getting to a point where we are going to have problems with Let's Encrypt. So we are going to work on defining the pre-flight checklist, meaning we are going to make sure that everything that we do need from the user is fully operational. And only if we have that satisfied, we will go further with Let's Encrypt certificate requests. So ultimately, we turn things around. Instead of saying, let's build Let's Encrypt, we are going to build everything before that to make sure that Let's Encrypt is working in 99% of the cases or as many cases as possible, obviously. The work on this hasn't started yet because we are lacking resources at the moment, but Q3 just started, so it's gonna be easy to do like this. There are a couple of other things that I'm really excited about that we shipped. I mentioned in our previous functional group updates that we did a lot of improvements when it comes to checking the licenses that we shipped. And we did more of them, where we now have a white list, the black list of software, we have white lists and black lists of licenses, and our builds actually fail if we detect a license that we did not check. So if you put something, if you put a Ruby gem in GitLab CE or EE that has a license that is not authorized by us, the package build will fail. And then we are going to come and hunt you down and find out why did you do that without checking the license and improve the process further, right? Obviously. This also helped us when we were discussing things with our licensing lawyer because we were able to present everything that we already have and which is usually not the case for us. We usually have to build something before someone, after someone asks us to deliver something to them. So I'm really excited about that. We're also working on making sure that the installation process is great. Joshua has been collecting the issues and fixing a lot of them. So great work by Joshua there. And we decided to also make sure that our installation documentation inside of Omnibus GitLab is good. Our documentation grew with the things that we added like additional services and so on, but we did not update the general documentation to make sure that the user who for the first time encounters the repository can find the things easier. And two other things that I listed here. QA is part of the triggered package build and new release process. I'm going to go into a bit of detail for each of them. Previously, we announced that you can build your own package and your Docker image. We now are working on expanding this where you will be able to trigger a package and image build and have that same build run a few full QA tests, which I think is going to be a game changer for our development. The improvements that we are going to introduce after this gets merged is we are going to work towards infrastructure that will allow us to get the build times of the packages, Docker images and the QA down. Right now, this whole pipeline takes two hours, which is not that bad, but it's definitely not good. So if you have a one hour run of your feature tests, one hour more for everything else, I wouldn't say it's too bad, but we can definitely improve it. And when we get to a point where we can reliably say this pipeline is going to take the same amount of time as the test pipelines that we have for our GitLab C and E, we are no longer going to offer you that luxury of not testing your package. We are going to enable this by default for everyone and we are going to leverage our multi-project pipelines to get you that feedback right there in your merge request. So if the QA fails somewhere because of a change that wasn't properly introduced into QA or because you broke something, your merge request is going to fail. Amazing work by Djegos, Remy and Baloo there. I cannot wait to see this in reality. This is just going to be amazing. And to finish off on an even higher high, with 9.4, we are introducing a completely different package release process. Our release process was built long time ago before we had the procedures in place and I think it got started when we were starting the screen sessions to build every single package. We outgrew that. It's obvious we have community, we have customers who are asking us, hey, I see a package out and it already installed on my server. So I don't see a blog post is the release out. What's happening? And at that moment, we are still trying to deploy this on github.com. That is definitely not good. So what we ended up doing is we separated, built from upload to a temporary location and then introduced a manual action, at least for now a manual action for our release managers, which will not have to panic anymore when the packages are built. They will be able to deploy on staging, deploy on Canary, deploy on production from a private repository that is not going to be world accessible yet. And once they are confident and once we are confident that we have a package that is working correctly, that we don't have any major regressions, release manager is going to use our CI and they are going to press that play button for each and every package and that package is going to be released to public. Not only package, this is going to be the same for Docker image and for our Raspberry Pi builds. So I think this is going to be a game changer for us, for our release process and one of the first big improvements that are going to happen for the release. I think that's about it. I managed to compose this at 17 minutes but my practice runs were 15. We'll be better next time. So let me take a look if there are any questions. Awesome, yeah, everything is awesome. I don't think I had a functional group update where I didn't present any lowlights. We obviously have them but I'm not going to present them because this is just so exciting. Awesome, if you don't have any questions, have a great rest of the day and talk to you at the meeting. Bye.