Current state: When a setting is changed in the GitLab Custom Resource (CR), unneeded components are not automatically deleted (and require manual deletion).
Desired state: When a setting is changed in the GitLab Custom Resource (CR), unneeded components are automatically deleted.
Acceptance criteria
Related components are automatically deleted if a setting is disabled
@dorrino I moved this into the 15.6 release, so we have an impactful operator feature in the release. In exchange I moved gitlab-org/charts/gitlab#1177 back into For Scheduling as it just hasn't been an important item for us.
This is borderline a typebug. Because the controller can not update the state of the GitLab instance after the spec changes.
To fix it we need to build a manifest of the resources that belong to a GitLab instance and by comparing the current manifest with the desired one we can identify the resources that are need to be updated and deleted.
This is pretty much what Helm does.
There are two ways to build a manifest of current resources:
Save the manifest after reconciliation, for example into ConfigMap. This is what Helm does with its releases.
Populate the resources that belong to the instance. We mark the ownerReference of the resources that belong to an instance and we can use it to find the resources.
The former might seem easier to implement, however it can be fragile and less reliable when the errors surrounding it are not handled properly.
Populating resources, which shows the true current state of the cluster, is not difficult with metadata client and we can leverage it along with discovery client to accurately build the manifest of current resources that belong to an instance.