 Hi, and welcome to the Configure Roadmap Update for January of 2019. My name is Daniel, and I'm the Product Manager for the Configure team here at GitLab. You can find me at gitlab.com forward slash Daniel Grusso. We love feedback here, so please feel free to reach out anytime. As you know, there are nine distinct stages of the DevOps lifecycle. The Configure stage is located in the Ops portion of the lifecycle. You can view the complete vision and category breakout in the link at the bottom of the slide. We deal with the configuration and operation of applications and infrastructure. We aim to make complex tasks such as standing up new environments or infrastructure fast and easy, as well as providing operators all the necessary tools to execute their day-to-day jobs. Our focus for 2019 will revolve around three themes. First is depth. We want our existing flagship features such as autodevops and our Kubernetes integration to be highly usable and cover the majority of use cases. The second one is empower operators. Operators are first-class citizens in GitLab. We want to continue to provide features that enable them to carry out their day-to-day activities right within GitLab. Lastly, we want to simplify the developer experience. We want to eliminate the pain of provisioning compute resources or infrastructure to run your application on. As I mentioned, the Configure stage is comprised of two main areas. The first one is infrastructure. That is the creation and configuration of the infrastructure where your application runs. This includes our Kubernetes integration, our serverless offering, and platform as a service or pass. For our Kubernetes integration, we'll focus on three main areas. First is cluster administration. We start with validating the credentials that you enter on cluster creation. When you add a Kubernetes cluster manually and enter data such as your CA certificate or your token, we want to validate that those are correct so that old subsequent activities on your cluster have minimal chance of error. We move on to Jupyter Hub for group-level clusters. This is the ability to deploy a Jupyter Hub instance on your group-level cluster so that all projects in that same group can take advantage of Jupyter Hub. Then we move on to instance-level clusters. Much like you can install a Kubernetes cluster at the project or group level, we want you to have the same ability at the instance level so that all groups and projects in your instance can take advantage of Kubernetes. We move on then to installing GitLab Runner on group-level cluster. Just like we have it today on project-level cluster, we want the ability for our runner to be shared across all the projects that belong to a group. And finally, namespace to environment coupling. Right now we can deploy a namespace per project and we want that to be more granular so you can handle things like authorization and security in a more granular way. The second area that we're going to focus on is the cluster app management area. We will focus on two things. First is upgrading the cluster apps. Right now when you deploy a Kubernetes application via GitLab, there's no explicit way to update it. So we want to make sure that that happens. We'll start with the GitLab Runner and this will be kind of paving the way for the rest of the applications. And then the second thing is uninstalling apps that have been deployed to your cluster. The third area that we will focus on is cluster creation. As you know, right now we provide a one-click way to create a GKE cluster and we want to provide the same ability for all major clouds. So we will continue with AWS EKS cluster creation. Much like we do for GKE today, the ability to easily create a cluster on EKS. For our serverless category, we'll also focus on three main areas. The first one is function detail. Here we want to show you the function scale. That is the amount of pods that have been deployed to serve this function as well as the function invocation count. The number of times a certain function has been called. And lastly, we want to be able to show you the cluster environment for the particular function. So when you view the function detail, we'll show you if this cluster is a scope to a particular environment. We then move on to eventing and that is mainly around function triggers. So what we want to do here is add a GitLab event source for Knative so that you can configure when a GitLab webhook is fired a certain function that has been configuring Knative being executed. And lastly, we want to also add detailed failure causes. Whenever something fails in the serverless implementation, we want to be able to show you all of those errors right in the GitLab GUI instead of you having to go to the Kubernetes logs. So things like errors in your GitLab CI file or your serverless.yaml file we want to service those right in the GitLab GUI. The last category for infrastructure is going to be pass or platform as a service. This is a new category for us in 2019. So we will be doing some discovery as to the approach we want to do for the final implementation of this feature. And we hope that the MVC, which is subject to change, will be that everyone gets compute. When we realize that your project is at a good place where it could take advantage of compute resources such as to deploying a review app or such, then we will go ahead and do that automatically for you. It's still early for this, and as I said, we love your feedback around this feature. The second main area of the configure stage is operations. That is providing operators all the tools they use on a day-to-day basis. This includes runbooks, chat ops, and cluster cost optimization. First, in runbooks, we're going to focus on project and group level filtering for your Jupyter Hub deployment. And that means providing access to the notebooks only to those members that are part of your project or group. Then the second thing is going to be repository integration for Jupyter Hub. And what this means is the ability to see and use the files that are on your repo while you are on your Jupyter Hub notebook. And additionally, the ability to version and store your notebook right in your GitLab repo. The second area here is going to be chat ops, and the focus here is going to be moving chat ops to core. So chat ops is currently in the ultimate tier, but we really want to promote adoption and we want to be everybody to be able to benefit from this feature, and to that end, we'll be moving it to core. And then the last thing is cluster cost optimization. We recognize that compute costs are a significant expenditure for many companies, and to that end, we want to provide you tools to be able to manage these costs and change accordingly. The first thing that we're going to focus on is flagging over provision Kubernetes deployments. And basically what this means is that if not all of the resources in your cluster are being used, we want to be able to inform you of this so you can take the necessary measures. The third category managed by the configure team is autodevops. Autodevops provides a predefined CI CD configuration that allows you to get a modern workflow automatically with minimal effort. This effectively a CI template that provides most of our best features out of the box. Our focus for autodevops starts with configuration. Here we'll start with moving autodevops domain away from CI CD settings and moving that into cluster settings. This will make things such as configuring base domains when you're using multiple clusters a lot easier. We then move on to autodevops support for environment specific custom domain. That is the ability for you to provide a custom domain, not just a base domain, so to deploy your application to a specific environment. Then we move on to management. And here we want to provide greater flexibility in how you manage autodevops in gitlab.com. And we'll start with the ability to enable or disable autodevops at the user space level. And that is if you have a gitlab.com instance and you have a hundred projects, you're going to be able to enable or disable autodevops universally for all of those projects. And lastly we have build and deploy. Here, as you know, you can store autodevops secrets using environment variables. And here we want to make sure that when there is an environment variable change, that is not accompanied by a code change from your application, that we redeploy all of your pods with the updated application secrets. And lastly, we want to use canico to build containers in autodevops. And that is so that we do not have to make use of Docker and Docker and privileged runners. And basically then reducing risk when you're doing builds. That does it for the short-term roadmap for the Configure team. Please remember that some of the content is subject to change and we use the content in the issues as the single source of truth for implementation and dates. You can also read more about our vision for the Configure stage by following the first link on this slide. The vision page will also link you to all the relevant epics and issues we discussed during the presentation. Also, feel free to contact me. I'm at gitlab.com forward slash Daniel Crusoe, or you can email me at daniel at gitlab.com. Thank you. See you next time.