Page MenuHomePhabricator

toolforge: consider relocating core k8s components out of puppet into its own repository
Closed, ResolvedPublic

Description

As of this ticket, some core Toolforge k8s component configuration live in the ops/puppet.git tree. We're expected to load them all by hand into k8s. Puppet doesn't do it.

List of stuff (probably not complete):

  • RBAC (toolforge::k8s::config i.e, modules/toolforge/files/k8s/toolforge-tool-roles.yaml) -- now on maintain-kubeusers
  • PSP (i.e modules/kubeadm/files/psp/base-pod-security-policies.yaml) -- not using them now
  • calico (i.e modules/kubeadm/templates/calicoctl.yaml.erb) now live at https://gitlab.wikimedia.org/repos/cloud/toolforge/calico

I don't think we have a lot of value having all that YAML coupled to the puppet git tree. Like what happened with the ingress component, we could move all that to a separate repository maintained as helm charts or whatever.

Some docs:

Details

Related Changes in Gerrit:
Related Changes in GitLab:
TitleReferenceAuthorSource BranchDest Branch
calico: delete old manifestsrepos/cloud/toolforge/calico!2aborreroarturo-calico-delete-old-manifmain
calico: initial code dumprepos/cloud/toolforge/calico!1aborreroinitial-code-dumpmain
Customize query in GitLab

Event Timeline

aborrero moved this task from Inbox to Soon! on the cloud-services-team board.

The base RBAC is a good candidate for moving into the maintain-kubeusers repository, I think.

The base RBAC is a good candidate for moving into the maintain-kubeusers repository, I think.

The file only has a tool-observer role, and a PSP for the build service.

Perhaps is worth folding into some kind of security repo (no PSP keyword in the name of the repo given the rework that will happen to PSP soon in a few k8s versions)

What do you think?

Will this include creating a repo for toolforge where we bundle up all these components or similar? (something like a toolforge repo with a helmfile pulling all the others)

I'm a bit concern on the sprawl of components without keeping track of the combinations that are deployed.

If so, that might belong to that repository.

I'd prefer to keep those in an existing repository. I think tool-observer should be in maintain-kubeusers which has everything else for tool and user rbac setups. And the build service PSP either there or in the build service repository.

Will this include creating a repo for toolforge where we bundle up all these components or similar? (something like a toolforge repo with a helmfile pulling all the others)

That is planned as a future part of T320667: Cloud services enhancement proposal: Toolforge Kubernetes component workflow improvements.

Will this include creating a repo for toolforge where we bundle up all these components or similar? (something like a toolforge repo with a helmfile pulling all the others)

I'm a bit concern on the sprawl of components without keeping track of the combinations that are deployed.

If so, that might belong to that repository.

Yes, that's described in T320667: Cloud services enhancement proposal: Toolforge Kubernetes component workflow improvements, i.e, adopt some kind of gitops. But first we need to get stuff out of the puppet git tree.

Change 894641 had a related patch set uploaded (by Arturo Borrero Gonzalez; author: Arturo Borrero Gonzalez):

[operations/puppet@production] toolforge: kubeadm: drop calico deployment

https://gerrit.wikimedia.org/r/894641

Change 894641 merged by Arturo Borrero Gonzalez:

[operations/puppet@production] toolforge: kubeadm: drop calico deployment

https://gerrit.wikimedia.org/r/894641

aborrero claimed this task.
aborrero updated the task description. (Show Details)