GitLab GitLab Group Kickoffs - Enablement:Distribution, 17 Sep 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: GitLab 16.5 Kickoff - Enablement:Distribution

Description

Scheduling Issue - https://gitlab.com/gitlab-org/distribution/team-tasks/-/issues/1320

A

Hello: everyone, my name, is Dylan Moreno and I'm. The product manager here at GitHub for distribution and today I'm going to be kicking off our 16.5 release.

A

Here is our scheduling issue. We are finishing up the quarter here, so um we will be creating a new issue for 16 6 16 7 16 8 coming up here, um but rounding out the quarter. We've got you know, okrs. We had planned to work on for this quarter um and then looking into specifically this Milestone um a similar theme so same of the top two items from 16-4 and even 16-3. uh We're gonna be moving forward with so continued progress on operator, production, anus and dependency updates and general efficiency around our dependencies.

A

So diving into our deliverables board I did want to bring this up just kind of show um in general we're working on. So you can see that um when it comes to dependencies, you know adding support for open series 15.5 reviewing our kubernetes support policy.

A

um You know, there's our operator issue but supporting gitlab kubernetes on 1.26 and we're also reviewing actually 1.27 um investigating further support for postgres right now, um so yeah I just want to show uh you know a heavy volume of dependency, research and updates um for this quarter and moving into uh the next piece which I mentioned. Is our operator production, Readiness?

A

There's two items here that we want to work on um I'm, going to talk a little bit more about something that we've recently brought up for the operator so jumping into our core dependency work. um This is the Epic that I showed last month, but I wanted to show it again um right now. This is more of the process Improvement one.

A

So one of the issues that we currently have is the review and Define kubernetes version policy, so I'll jump into that in a second, but you saw all the other updates that we're going to be working on kubernetes, open source postgres, some of the big ones, and this kubernetes research will kind of dictate our policy for other dependencies that we we work with. So I just want to bring this one up and talk a little bit about it. So currently we have a policy or the adoption in, for let's say: kubernetes isn't completely documented.

A

We document which version we support, but we don't document sort of our timeline for supporting these items or necessarily commit to anything. We try our best to introduce these as soon as we can, but moving forward. We want to be a little more rigorous for customers so that they can anticipate that you know when a new version of kubernetes comes out. Gitlab will support it in X number of months.

A

So that's something we're going to investigate here on what is theoretically possible I'd love to say that we could support something immediately when it comes out, that's not always possible when we can't anticipate when something's going to come out, but as far as testing goes and making sure everything works with all the other dependencies we work with for something like kubernetes.

A

um You know it might take a little bit longer. Some of the challenges here that I'm mentioning is that you know we can't always guarantee a plus one or minus one versus support for for things that we ship that are related to kubernetes um such as cube CTL, um and then you know, for example, with the operator there might be a lag in supporting the operator versus kubernetes version. So those are the kind of things we're working with, so we're going to investigate it and then come up with a more specific policy.

A

So our customers and users can anticipate um what version of the kubernetes are in support and, like I, said what we come up with here. We'll use this kind of foundational for for the other packages.

A

um You know os's um other. You know random dependencies that we support so looking forward to that moving into the operator. So we've been talking about the operator for a long time and we're approaching the production of Readiness. So we currently have two issues that um are related to our parity with a home chart. I would say at the moment, um but the main piece that I want to talk about for the operator and production Readiness is actually investigating a new UI.

A

So at the moment um the operator sort of depends on a custom resource definition that is maybe challenging um in some ways or not intuitive, to work with. So in this case you know we would like to make the UI a little more intuitive and different.

A

um What that means is if a customer installed the current version of the operator, and then we make this switch, they would then have to migrate. So we do have currently you know some users and customers using the operator, which is fine. uh You know they they knew or you know you should know that it's not production rate at the moment, but moving forward when we make this switch they'll have to migrate. So before we actually go forward and say the operator is production ready.

A

We want to actually make this change so that we don't have many users requiring to do this manually. So we want to make this change and make this a lot easier to use. You can read through this here, I'll make sure to link it in the scheduling issue, but this is one of the huge things we want to work on in 16.5 so that you know moving towards 66 167. We get closer and closer to a new user experience for the operator and a production review operator. So thank you so much.

A

Those are kind of the two main themes we're going to be working on for 16.5 and we're looking forward to seeing you next month. Thanks have a good night foreign.