search

hashicorp / terraform-enterprise-helm

The official repo for Terraform Enterprise helm charts
Mozilla Public License 2.0
16 stars 17 forks source link

Consider non-helm Kubernetes deployment options? Static file? #34

Open nairb774 opened 1 year ago

nairb774 commented 1 year ago

Helm is popular and all, but the requirement to learn yet another API (values file) means that your helm chart is going to be unique and different from any other deployment on Kubernetes. Rather than being able to deploy TFE like any other Kubernetes application (Deployments, ConfigMaps, Secrets, ...) the helm chart introduces a layer of abstraction that, for applications which map to Kubernetes well, can be more of a negative and increased complexity than provide any value.

While the current chart looks to be in the early stage (woo!), it is also demonstrating the significant downsides of helm. Every existing Deployment API is being passed up to the values file (example). While this does allow users of the chart access to some of the settings, it also prevents access to others. For example, if additional labels are desired on the deployment for tracking, compliance, or other needs, there isn't (currently) a way to express that configuration with the current state of the values file. And while this is a small example, it is that continuous treadmill of chasing the dragon's tail, yet providing limited value and often placing updates to the chart between users and their ability to get things done.

It is also reasonable to support helm as well. There are a lot of organizations that have consolidated around it due to the packaging element and it is reasonable to support them. However, I would encourage supporting a "static file" style deployment as it can be both easier to get started as well as it can encourage keeping the deployment, upgrade, rollback and overall system management simpler. For example, a static file doesn't have support for pre/post hooks and while this can be limiting in the overall deployment, it also can help reduce some of the odd failures that happen when helm gets stuck in an half-upgraded mode because some job got angry and refused to work correctly. The end result is the system is designed to be upgraded slightly differently, and often is a net benefit.

I'm super excited to see the Kubernetes offering in beta, and while it's clear I'm not a huge fan of Helm, I really appreciate that this will allow us to eliminate the last non-Kubernetes workload in our infrastructure. It is perfectly reasonable to want to only support helm, I just saw an opportunity to shape the beta and figured it would be worth a shot.

amy-hashi commented 1 year ago

Thank you for the feedback, Brian. I will document this internally and we'll discuss.

ETA: Internal tracking TF-9954