Feature Request: Helm Chart

[brad-taylor-yvr]

Any thoughts about / plans for creating a Helm Chart?

As is, it is a bit of a lift to convert the 30-odd resources in https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy-operator/v0.5.0/cloud-sql-proxy-operator.yaml into something that can be orchestrated with Terraform, which will become out of date at the next release.

thanks...

Specifications

• Version: v0.5.0
• Platform: n/a

[hessjcg]

I like this idea. I'd like to explore the requirements a little bit before we make a commitment to do it. Here are a few questions for the community:

What parameters do you need on the operator helm chart?

Here's my preliminary list

• Operator Version (default latest)
• Number of replicas for the operator deployment
• Operator pod configuration:
  • resource requirements
  • labels & annotations
  • affinity

Could you elaborate why helm is better for you than kustomize? There is a Kustomize project layout the config folder in this repo, but we haven't documented how to use Kustomize to deploy the operator yet. I imagine that you prefer Helm to Kustomize.

[brad-taylor-yvr]

For me, Helm > Kustomize purely because of familiarity.

I know how to run Helm charts in Terraform (which I have to use). Kustomize is new to me. Looks great, but do I have to convert everything to Kustomize? If so, that's a non-starter. ;)

Other Helm charts I use include installCRDs yes/no namespace override

thanks for the quick answer back :)

[brad-taylor-yvr]

Hi team, I know you've been hard at work getting to the 1.0.1 release. :) Any more thoughts on this request?

[enocom]

Does the list of parameters look good to you @brad-taylor-yvr from

[brad-taylor-yvr]

Hi that list looks ok to me

• Operator Version (default latest)
• Number of replicas for the operator deployment
• Operator pod configuration:
• resource requirements
• labels & annotations
• affinity

I also mentioned in the following comment:

• installCRDs yes/no
• namespace override

If Operator version is not the way to pick the version of the cloud-sql-auth-proxy image, then that would be useful too.

Along the same lines, if the version of cert-manager is non-deterministic, it might be useful to be able to change that too?

thanks... :)

[enocom]

Given the interest here, we'll work on prioritizing this.

[thomas-riccardi]

an additional point of view on the matter: the helm chart would help us indeed with terraform

helm vs kustomization

The helm terraform provider is maintained by hashicorp, and is battle tested and well known by the community. We have not yet tested the community kustomization terraform provider.

CRDs installation

The CRD story is critical for migrations from a previous kind of deployment: we cannot just delete everything and start again: workloads use the CRDs!

For helm: I would recommend the method 1 documented here: https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#method-1-let-helm-do-it-for-you

• It avoids accidental CRD deletion: helm handles explicitly itself the CRDs and only ever creates them
• helm tolerates pre-existing ones (modulo manually adding some labels to simulate a previous installation by helm))
• helm also allows to not install them for those who prefer that

misc

terraform cloud started billing by the resource: helm charts become even more interesting (vs ~30 kubernetes_manifest)

[hessjcg]

Adding a feature to the helm chart values: #461: List namespaces monitored by the webhook.

[hessjcg]

I just created a very early Proof of Concept helm chart. I would love your feedback as I design this new feature. See #483

[via-justa]

Is there any update on that? The PR has been stale for many months.