GitLab Distribution Team Demos, 18 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Distribution Team Demo - 2021-02-18

Description

Charts: Gitaly to Praefect
https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/1757

A

Hello: everybody thanks for jumping into the distribution team demo for this week uh as I'm on triage today's thursday february 18.

A

uh today, I'm going to run through the mr in the gitlab chart for supporting migration from gili 2 prefect scenario here is that there's a deployment of the helm chart with just basic settings using one gitly node and then we'll turn on prefect and it's backing goodly nodes and transfer repositories over and then remove the old standalone. Giddily prefect has become more of a hot topic lately so figured it was a good time to touch base with the team and show what's going on with it lately.

A

So the mr is here and in the demo notes. I have already launched an instance in gke and that's here. All I have so far is prefect, enabled false, which is the default anyway, and so what I'm going to do now that step one is done, is go to step two, which is just create a project, so we have something to migrate.

A

Just give it a readme.

A

The project is there I'll quickly go over to the admin area and show italy. Servers is just the default, so it points directly to that standalone gitly instance.

A

So we'll do now is uncomment this section. So now we'll do prefect enabled true. This is a new key. That's part of this, mr replace internal goodly, is now set to false by default. This is true, so if you turn on prefect, what will happen is that the standalone gitly stateful set will not be deployed and instead only the prefect managed gitly instances will be created. So by setting this to false we're actually going to keep the existing standalone giddily stateful set running and alongside it, deploy the prefect managedly instances.

A

So by default, there's a virtual storage for prefect named default because there always has to be a storage name default in gitlab.

A

What we're going to do here is because we already have we're keeping the old goodly stateful set running, which already has the storage name of default. What we're going to do is just pick anything else. In this case, I've just been doing vs2 for virtual storage 2 and putting prefect after it just to be clear where it's managed uh to get a replicas and max and available are similar to the settings. You can do a standalone gigalite, just showing how many replicas will come up.

A

So we're going to do here is create a new storage called vs2, prefect and so the default and vs2 prefect storages will both be connected in gitlab. That's what will allow us to kick off the migrations api to migrate, the repositories to that specified storage, then, after that we can actually turn off the old one.

A

So I will go ahead and redeploy.

A

There's one manual step in here: we have to create the database by hand. So, as that comes up we'll go down to our postcards chart, I mean a.

A

A

Now we're in create a role.

A

Grab the secret.

A

Least name here is gitlab.

A

A

A

A

A

So now you'll notice.

A

We've got our prefect pods coming up.

A

And you'll also see we have our old giddily zero pod still running, and since we specified two giga replicas for virtual storage, two you'll see the storage name in the staple set, as was released last time and you'll see both pods there. Under that storage name,.

A

Insufficient cpu.

A

That should be okay, so as those pods come up, we'll just confirm that those storages appear under here now. Here we go so now: we've still got that old default storage, but now we also have vs2 prefect.

A

So now what I have is, I have two scripts here. This is from the migrations api docs, effectively we're going to have a token created in this instance already. So let me go to create that.

A

It's going to need the api and read api.

A

Scopes and I'll delete this after the demo.

A

I'm just going to put that in a file called token.txt for my script to read so as these come up, I think we should be okay. I still see one web service pod is coming up. What I'm going to do is effectively just run this move.sh script, which will basically make a choral quest. So you can see our source storage name here is going to be default.

A

If I go back to the admin area, goodley servers we're going to go from default over to vs2 prefect. So in my script I have the sources default and then the destination storage, name, vs2, prefect and then my url here.

A

So we got a message accepted. That's good! If your api token doesn't have the correct scope, you'll get an unauthorized response here; otherwise it should take it and then there's a second part where you can actually query the status of the moves. So what we're going to do is run check.sh and we'll pipe it to jq for readability cool. So, with this response here, you'll see the state is finished uh in the past. When I was testing this and it failed, I would see the just a failed message there.

A

So you can see my before prefect repository was moved and the one that comes by default. The monitoring project was moved so effectively. Now, there's nothing stored on the default, gita storage, so we can actually remove it. So the next step here is.

A

Is to go to the next block.

A

So now our migrate projects to vs2 prefect, uh which is what we just did so now we'll go uncomment this last section. So now we'll still have pre-effect enabled as true now we turn replace internal giddily to true, whereas before it was false, so now it will actually replace that standalone goodly instance, and then we still have this same virtual storage that will still exist, but now we can actually, since we're removing the old default virtual storage. We can add a default storage because remember there always has to be a storage name called default.

A

So we will do one final.

A

A

So you should see that pod disappear and a few more pods pop up under the default storage.

A

A

Perfect, so these three are launching now and gilly. Zero is.

A

A

And once they're up, I will refresh this page and confirm that those storages are connected.

A

Give a second for prairiefact and get lab to catch up to change.

A

A little slow today.

A

Now this page has configuration coming from web service itself because there's the gate lab ammo that specifies all the storages to connect to. So as these new pods come up, they're going to get that new configuration as templated by the.

A

A

So we must still be hitting this old.

A

A

I'm just going to go ahead and bounce. It.

A

Did it on its own.

A

One last thing is as we're looking at this. Obviously, the projects are all going to be stored in vs2 prefect at this time and default will be empty, so one possible option: that's not required is to adjust this script, to change the source storage name from vs2 prefect over to default. You could shift all the projects over to the default storage that migrations api can be used anytime. Whenever you want to shift between projects.

A

So now the pods are up. They all over. The new configuration we've got default, which is a prefect virtual storage and vs2 prefect same thing, and so, if we go back, we should still be able to load our project from before prefect.

A

There you go, no errors.

A

That's really it so. A bulk of the work of this, mr, was adjusting the logic to be able to get standalone giddily to deploy, alongside giddily, with prefect and so you'll notice that we've split out most of the spec into their own separate files so that they can be ingested by either standalone, goodly or prefect.

A

That's the biggest change, you'll notice there, that's about it for the demo. Are there any questions on that.

B

Mostly a curiosity back in your values.yaml, we go back to there uh the the step number four. If, if we reapplied that I'm curious, what the effect of replace internal giveaway would have now that we have just the uh virtualized or virtualized storages, does that just now basically get ignored or is that going to cause more damage.

A

Yeah that replace internal giddily is kind of a switch on which resource to deploy. So, if I go to the gilly templates.

A

You'll see here we have all the resources are split out into individual spec files, so they can be either included by service with prefect, for example, or just service okay. So so that's really just the guard so effectively. It's just allowing certain resources to get templated or not. That's basically, the extent of the.

B

Project of replace internal.

A

Goodly there part of the mr, is that we um adjusted the logic replace internal italy.

A

We put it into a template here, so.

B

So if it's a switch to which resources get applied, uh does that mean that at any future, deployments of the helm chart to this cluster would need to have that turned on? Otherwise it would switch it back to using the internal get only.

A

Yes, the default is uh under values here, replace internal, so the default with pr, if you turn on prefect, is that it will replace internal gateway.

B

A

The same his the same logic will apply even with this new flag. This is effectively only in the scenario where you did not have prefect in the past, and you want to migrate to using prefect and get those repositories migrated over. If you don't set this, it will keep the default of true and still just replace internal gigily, and if.

B

You have prefect off.

A

B

Yeah, that makes sense. Okay, good, I'm just trying to understand the scenario there good question.

A

A

Looks good man.

A

Awesome thanks everybody. I know there's some issues now where the teams want to start enabling prefect by default in the charts. So I think topics related to prefect start coming up more and more often, so I don't think it's quite at a point: we're ready to enable it by default, just because we're looking for a little bit more out of the logs and a little bit clearer documentation on uh how prefect works, especially when scaling up and down. Obviously that value that I set for getting replicas is very easy to configure.

A

But if you bump it up or down, prefect gets a little bit angry at the storage names now that it's keeping track of those in the database.

A

So we've got some open issues I'll log in the demo notes here, where we're talking about with those teams, but for now at least the migration, if you didn't have prefix in the past, will work just fine.

B

A

Awesome thanks: everybody have a good day.