GitLab Configure Stage, 17 Aug 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 14.3 Kickoff - Configure:Configure

Description

https://gitlab.com/gitlab-org/configure/general/-/issues/153

A

Hi, it's viktor knight, the product manager of the configure group- and this is our 14.3 milestone, release kickoff. Let's see what do we plan to work on this milestone.

A

This is our planning issue. As you can see, we have quite a few goals here. First of all, we would like to ship kubernetes, 120 support and the stretch goal 1.21 support. This is especially important for us as bytes as of today. Even the major cloud providers support both 120 and 121, and we are very.

A

Behind the hyper clouds and our users want to use these kubernetes versions with the cloud provider. The second goal is to ship the group level c item. This is deliverable as well.

A

I will speak a little bit more about this in a minute. Let's see actually so the group level ci tunnel, we ship the cicd channel at the project level in as part of 14.1, and this allows a gitlab, ci cd job to target a cluster connected using the gitlab commands agent. This is especially important feature for us because we believe that most of our existing users use github, ci cd and a manually configured cube config setup to deploy to the kubernetes clusters using the cic tunnel.

A

They can use the agent as the connection between the runner and the cluster. They don't have to set up custom runner feeds. They don't have to set up a massive cube, config file there. They can just use our integrations, especially as as of today, we even inject the cube config that is available for certain job. As I said in 14.1, we had this feature the project level only and in 14.3.

A

We want to ship it at the group level as well, which will enable an agent to be reused for all the projects within the group and as well. We are actually adding uh specific project support, so the an agent can be used from a different project as well.

A

I already spoke about the kubernetes version support. This is more of a we have to check if all the features work for the first time ever, the container security scanner will be checked as well thanks to the container security team. So we try to provide really a full support of gitlab features in these versions.

A

The next item for us was to move the agent to core, but, as one of our engineers is helping out the verify team- and we have quite a few ptos this milestone- we removed that from from the features that we we could actually develop here.

A

So uh I'm moving on the next item. The next two items are actually around front-end improvements. First of all, we want to improve the agent listing today. The list is really really minimal. I'm going to show you a quick example here.

A

Basically, we just show the agent name and the configuration file a link to that configuration file actually in the next iteration. We want to improve this listing by connection status last contact time.

A

The version of the agent k component installed in the cluster command's version, the version of the cast server and all this information and necessary primary for troubleshooting purposes to have a quick overview of what, if there's any issue with the agent, whether it's something easy to understand, or they have to look deeper into whether they have to log into their clusters and see the agent logs or they can just see from here that there's a connection error.

A

The second front-end heavy item is to change our ux around our kubernetes views. Again, if you go back to this example, you can see that we have two tabs and if I go to the agent manage ones, I refresh the page, it reloads on the cluster managed ones.

A

Here. This tab is secondary. The agent managed not because the cluster management the certificate base would be recommended, but it's secondary because it's a core feature by agent as a primary feature of today.

A

Moreover, if somebody goes on the connect cluster certificate, they get a totally different design. Again, we want to change, want to fix this design, actually using a rather big redesign, where we would have much better ux thanks to justin.

A

Finally, we have two issues that are for design.

A

One is we want to provide an activity information list in the agent details page today, the agent details page is truly minimal, as you can see it here, we just provide you a list of the access tokens, but actually we would like to provide here more things like again to have. The troubleshooting would like to provide a list of the events that happen with this agent, either in the connection between gitlab and the agent or simply inside the cluster, like synchronizing, the pool based fashion.

A

This is one of the items that we we are designing in the next milestone.

A

The final item that we want to design is again a preparation for a for a bigger feature that would be user based, cube, config using gitlab agent connection, a user-based cube, config means that, to connect to a cluster you need people needs need a cube, config file that contains a token to authenticate with the cluster.

A

With the gitlab commands agent, we can provide this queue config file from gitlab, so the user doesn't have to know whether the cluster is in gcp or aws and what command line they have to use there. They can just go to the github ui and get this cube config easily in today, local environment, with all the authentication as well using personal access, token and so on.

A

So these are our plans, and if you need more details, you can have a look at our planning board that contains all the issues that are described at a higher level here or you can have a look at our roadmap that spans a little bit further out as well into the future.

A

Thank you very much for your attention.