## Goal There is a [growing need to](https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/1632) develop an easy-to-use solution that internal teams can easily leverage and manage ClickHouse instances. The aim is to have a single, automated, resilient way of deploying and managing ClickHouse in a single place that is "on by default" in GitLab deployments. Consumers (those that need the database, i.e. Opstrace, ErrorTracking, etc) can request a DB instance through an authenticated API and receive a connection endpoint. ## Iterations ### Iteration 1, ending April 22 - [Implement ClickHouse operator, use in Opstrace Controller](https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/1643) :white_check_mark: - [Clickhouse Production readiness review](https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/1644) :white_check_mark: ### Iteration 2, ending May 6 - [Design a v1alpha1 CRD for requesting a ClickHouse backend.](https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/1649) :white_check_mark: - [Clickhouse is installed by default in GDK](https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/1650) :white_check_mark: ### Iteration 3, ending May 20 - [Reconcile CR by creating/updating/deleting ClickHouse instances/databases](https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/1648) :white_check_mark: - [Update CR status and use Kubernetes events recorder to provide useful information on reconciliation progress/errors](https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/1647) :white_check_mark: - [Deploy CHProxy as part of each CR to enforce limits and access control (basic auth)](https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/1646) :white_check_mark: ### Iteration 4, ending June 3 - [Ensure End-to-end test pipeline in CI for ClickHouse Service](https://gitlab.com/gitlab-org/opstrace/opstrace/-/issues/1645) :white_check_mark: