[kuschku]

That’s the one I’m using, but based on today’s release page saying the Helm chart is deprecated and I should use the cloud-native GitLab chart, and based on what your link to the Omnibus chart says:

> This Helm chart is in beta, and will be deprecated by the cloud native GitLab chart.

I interpreted it as this being deprecated.

That said, great work on performance and startup times in the past months, for the first time my 2-user GitLab isn’t maxing a full core and using 6GB RAM anymore, but instead using 60% of a core and 6.3GB RAM, while site load times have gone down significantly, and startup now completes actually within of the first 5 minutes (before, Kubernetes’ readiness checker often killed GitLab before it managed to come up)

[joshlambert]

Hi Kuschku,

Sorry for the confusion, as noted we are trying to remedy this with a single chart as quickly as possible.

Currently we have two Helm charts that can deploy GitLab, "gitlab" and "gitlab-omnibus".

* The "gitlab" chart deploys only GitLab itself and is not recommended. This is the chart that has been announced as deprecated in the blog post.

* The "gitlab-omnibus" chart is what we recommend users to install today, and deploys everything you need for a working GitLab installation. (Postgres, Redis, an Ingress, etc.)

We still support and maintain the "gitlab-omnibus" chart, but it too will eventually be deprecated as well in favor of the upcoming cloud native charts.

The cloud native charts will have a significant number of advantages, including:

* Separation of components for improved horizontal scaling

* Improved resilience

* Faster startup time (current container runs `gitlab-ctl reconfigure` on every startup)

* No need for root access

Due to the significant architectural changes, migration will be via backup/restore.

[kuschku]

> * Faster startup time (current container runs `gitlab-ctl reconfigure` on every startup)

Oh my god, how much I'd love that.

On the topic of cloud native charts, can I use the new cloud native gitlab chart (if I run an external prometheus, postgres and redis already separately) today? And how would I migrate?

And one thing I'd love to see is building docker containers without having to give the runner access to the host's docker. How do other CI solutions do that?

[joshlambert]

> On the topic of cloud native charts, can I use the new cloud native gitlab chart (if I run an external prometheus, postgres and redis already separately) today? And how would I migrate?

The cloud native chart is still under development and breaking changes will occur, so I would not recommend using it for anything outside of testing. For example our current sprint is focusing on storage persistence.

For migration, you would perform a backup of the current instance and restore the backup onto the new cloud native based deployment.