Operator development steps and scope
This is an umbrella issue for capturing the steps for adding the necessary functionality to the operator for GA. This issue also serves as a description of the operator's scope. Based on the responses to charts/components/gitlab-operator#2 and charts/components/gitlab-operator#3 the following ordered steps seem sensible:
- Add logic to the operator to work out the current version of GitLab installed (by querying https://gitlab.example.com/api/v4/version or otherwise)
- Modify operator to ensure all deployments and statefulsets are unpaused and unpartitioned when the desired version specified by the GitLab CR equals the version of the current GitLab deployment
- Modify the gitlab chart to pause/partition all deployments/statefulsets by default and additionally to install the operator with the GitLab CRD/GitLab CR/operator RBAC rules. This may require pausing other resources such as Jobs
- Add logic to support upgrades of GitLab image versions only (with a maximum of 1 minor version and possibly with downtime and without rollbacks). It will be important here to ensure changes to the GitLab resource during an upgrade are dealt with gracefully and an event raised if there's an issue. Attempts to downgrade should error.
- Add logic to support upgrades/downgrades of image versions plus anything else (other resource fields/configmaps/secrets) in the same upgrade
- Support backups
Out of scope for GA
- Add logic to support upgrades of image versions only without downtime (with a maximum of 1 minor version and without rollbacks)
- Support downgrades to an arbitrary version by restoring from backup
- Add logic to support downgrades during an upgrade without restoring from a backup but before the post-deployment migrations are run (as mentioned here).
@Ahmadposten @twk3 @wortschi @WarheadsSE @marin @mattiasgees