fix: added gitaly cgroups init image to package

[JoeHCQ1]

Description

Downstream we use this image to modify cgroups on gitaly nodes to improve resiliency. This isn't in the package right now, so we're having to add it to a local package so it is available. By putting it here in the original package we ensure the version always matches the rest of the install, and save others who do similar work time later.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps followed

[zachariahmiller]

Per the discussion on getting this working you had posted about in slack, shouldnt securityContext need to be overridden in the common values for this even if its not being enabled so it works with uds with minimum configuration?

[JoeHCQ1]

Per the discussion on getting this working you had posted about in slack, shouldnt securityContext need to be overridden in the common values for this even if its not being enabled so it works with uds with minimum configuration?

Depends on the level of support we want to provide in this package for the custom init. Having the image available allows me to override things downstream at the bundle level until it works. We could backport the configuration settings too, but as it's broken again in my cluster for some reason, I'll have to wait on that changeset.

[JoeHCQ1]

Note: future work - given the link you shared: https://gitlab.com/gitlab-org/build/CNG/-/blob/master/gitaly-init-cgroups/Dockerfile?ref_type=heads we should be able to create our own unicorn and ironbank versions of that image fairly easily. I doubt it's worth the work yet, but if ever needed, it wouldn't be hard.

[JoeHCQ1]

From before Thanksgiving break, note from reviewer in slack:

left a couple comments. Also based on what that container actually has on it it seems like we might not actually need this dedicated upstream only container, since the source script should be in the gitaly container already.

[JoeHCQ1]

From before Thanksgiving break, note from reviewer in slack:

left a couple comments. Also based on what that container actually has on it it seems like we might not actually need this dedicated upstream only container, since the source script should be in the gitaly container already.

The script is there, but if swapped in for the gitaly init container, it errors out. They're relying on the dockerfile CMD rather than setting a command themselves in the k8s manifests. Therefore, the normal gitaly container just starts up gitaly.

[JoeHCQ1]

Per the discussion on getting this working you had posted about in slack, shouldnt securityContext need to be overridden in the common values for this even if its not being enabled so it works with uds with minimum configuration?

Depends on the level of support we want to provide in this package for the custom init. Having the image available allows me to override things downstream at the bundle level until it works. We could backport the configuration settings too, but as it's broken again in my cluster for some reason, I'll have to wait on that changeset.

The securityContext is now set in the common-values.yaml as suggested.

[robmcelvenny]

lgtm!

[zachariahmiller]

@JoeHCQ1 The required exception is missing from this. It needs to be in the config chart, templated based on a value, which defaults to false, with a note in the configuration.md on enabling/disabling.

[JoeHCQ1]

ah yes, that exception is probably in my nutanix bundle but it'd be needed here. Good catch.

[robmcelvenny]

LGTM