Talk:Wikimedia Cloud Services team/EnhancementProposals/Toolforge Kubernetes component workflow improvements

About using the repo commit hash for the image tag

There's a note there that says:

needs a separate commit or two to the same repository for deployment, but still gives us much better confidence on what we're rolling out and a better way to revert problematic changes

I think that's ok, for example: https://gerrit.wikimedia.org/r/c/labs/tools/registry-admission-webhook/+/841903

So I think it would not be an issue, it might even be good, as then you can release the image and deploy later, not needing to release and deploy at the same time. David Caro (talk) 11:50, 13 October 2022 (UTC)

Deployment plan order

I'm not sure we benefit a lot from introducing the deployment repo before having helm charts generated.

The submodules interim solution allows us to do so, but we will have to change the helm charts on the repos while they are submodules so it feels a bit cumbersome (and then handle the submodules upgrades and such).

What about doing it the other way around? starting with moving to gitlab, then generate/upload helm charts (while still having the helmfiles per-repo), and then creating the deployment repo with the general helmfile pulling the charts?

That will require having harbor (or whichever helm repo we use) around though. David Caro (talk) 11:54, 13 October 2022 (UTC)

Agree that submodules are not ideal. I've adjusted the proposal. Majavah (talk!) 12:35, 13 October 2022 (UTC)

Integration tests

Something I wanted to introduce too, for components that are quite impactful, like the registry-admission-webhook, we should have some kind of integration/smoke tests before enabling auto-deployment, though I'm not sure how easy that would be to setup on ci, needed k8s and such. David Caro (talk) 11:56, 13 October 2022 (UTC)