3 ms·

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

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 9y ago
> * 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 9y ago
  > 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.

kuschku 9y ago

> * 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 9y ago
> 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.