Skip to content

Object discovery: Handle duplicate resources

Clemens Beck requested to merge 1485-fix-delete-resources-with-wrong-api-version into master

What does this MR do?

The Operator deletes unneeded resources by comparing the resources applied to the cluster with the expected state.

When discovering the resources currently applied to the cluster, some of them are discovered multiple times because the API server response contains the same object for different group versions. For example:

> kubectl get horizontalpodautoscalers.v2.autoscaling -n gitlab-system --no-headers
gitlab-gitlab-shell          Deployment/gitlab-gitlab-shell          <unknown>/80%   2     10    2     18h
gitlab-kas                   Deployment/gitlab-kas                   <unknown>/80%   2     10    2     47m
gitlab-registry              Deployment/gitlab-registry              <unknown>/80%   2     10    2     18h
gitlab-sidekiq-all-in-1-v2   Deployment/gitlab-sidekiq-all-in-1-v2   <unknown>/80%   1     10    1     18h
> kubectl get horizontalpodautoscalers.v1.autoscaling -n gitlab-system --no-headers
gitlab-gitlab-shell          Deployment/gitlab-gitlab-shell          <unknown>/80%   2     10    2     18h
gitlab-kas                   Deployment/gitlab-kas                   <unknown>/80%   2     10    2     47m
gitlab-registry              Deployment/gitlab-registry              <unknown>/80%   2     10    2     18h
gitlab-sidekiq-all-in-1-v2   Deployment/gitlab-sidekiq-all-in-1-v2   <unknown>/80%   1     10    1     18h

As a result, the GitLab operator tries to delete the resource for multiple group versions.

  • These duplication/errors can be avoided by querying each kind only once.
  • If these not found errors occur during cleanup (for example, because the resource has been deleted by a user), we can safely ignore them.

Upstream Issue: https://github.com/kubernetes/kubernetes/issues/58131

Closes #1485 (closed)

Changelog: fixed

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Test Plan

  1. Install the Operator
  2. Apply a GitLab CR with a custom HPA API version (spec.chart.values.global.hpa.apiVersion=autoscaling/v1)
  3. Confirm the HPA are created as expected
  4. Disable the webservice component (spec.chart.values.gitlab.webservice.enabled=false)
  5. Confirm the webservice HPA is deleted as expected

Required

  • Merge Request Title and Description are up to date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline on GitLab.com
  • When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes
  • Documentation created/updated
  • Tests added
  • Integration tests added to GitLab QA
  • Equivalent MR/issue for omnibus-gitlab opened
  • Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.
Edited by Clemens Beck

Merge request reports