Helm Chart support

[stiliajohny]

Would you consider converting or supporting that being installed via Helm chart?

[adyanth]

Sure, I've always found it "simple" to use kustomize, but helm would be a nice addition if some one is willing to write up a template!

[stiliajohny]

let me look ino that, i also think i will attract more supporters

[HomeLabJunkie]

let me look ino that, i also think i will attract more supporters

Any traction on this. I would definately appreicate a way to install with helm

[gecube]

The only thing I'd like to ask in connection with Helm chart - is to put the CRDs either into /crds catalogue for a proper lifecycle (we don't have the better solution now) or separate it into another chart (effectively getting the CRDs chart and operator chart). Also it would be nice to have skip CRD install flag if the user of the chart wants to manage it separately. It is already done in projects like cert-manager: https://github.com/cert-manager/cert-manager/blob/9aa47a01ded1a47e772909f03a816f1a73680769/deploy/charts/cert-manager/values.yaml#L72

[cyclingwithelephants]

I've begun implementing this, and need feedback on managing the rbac. It's nasty enough that if we can't solve it cleanly I might abandon the PR

[cyclingwithelephants]

@adyanth and I decided not to implement this, as we can't figure out a way to autogenerate the associated k8s rbac. It's likely to be a lot of work keeping these up to date

I imagine PRs are always welcome, but realistically the maintenance of this is going to be a lot of work. I looked at cert-manager for inspiration and that seems to be manually handled, but they also get paid to maintain it

@adyanth can we close as won't do?

[adyanth]

I see an aloha support for helm via kube-builder, so i can keep this issue open for now to track

https://book.kubebuilder.io/plugins/available/helm-v1-alpha

[cyclingwithelephants]

oh that's exciting, absolutely

[thomaspetit]

Not really an answer to the question of having a Helm chart but this is my "workaround" if you want to call it that way.

What I typically do for projects that do not have a helm chart available is this:

---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - github.com/adyanth/cloudflare-operator/config/default?ref=v0.13.1
  - ./base

namespace: cloudflare-operator-system

patches:
  - target:
      kind: Namespace
      name: cloudflare-operator-system
    patch: |
      $patch: delete
      kind: Namespace
      metadata:
        name: cloudflare-operator-system

Why use kustomize is awesome? It also allows you to use Helm charts making it the perfect way to deploy both Helm as "native" apps. Here's an example for Cloud-native PG

---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources: []

namespace: cloudnative-pg

helmCharts:
  - name: cloudnative-pg
    includeCRDs: true
    valuesInline:
      monitoring:
        podMonitorEnabled: false
        grafanaDashboard:
          create: true
          annotations:
            argocd.argoproj.io/sync-options: ServerSideApply=true
    releaseName: cloudnative-pg
    version: 0.25.0
    repo: https://cloudnative-pg.github.io/charts

patches:
  - target:
      kind: CustomResourceDefinition
    patch: |
      apiVersion: apiextensions.k8s.io/v1
      kind: CustomResourceDefinition
      metadata:
        name: unspecified
        annotations:
          argocd.argoproj.io/sync-options: ServerSideApply=true