@gman0 Thanks for your willingness to contribute! We are discussing about this.

Hey @gman0

FYI: I recently worked on exactly this: https://github.com/piraeusdatastore/helm-charts/

My main motivation was helping users of Piraeus to enable snapshotting on their cluster, but I'd be happy if there was a "official" solution.

@WanzenBug thank you! That is exactly my motivation as well, but I just started working on this. From the first glance, your solution looks great, it even seems to offer deployment for the webhook. Would you like to take over this ticket? Of course that is if sig-storage folks think this indeed makes sense.

I would also really appreciate there being an offical helm chart, as it makes updating and installing so much easier.

Using helm to manage it would be preferable for us. It would make it easy to customize for our environment and keep it up to date.

We have yaml files that are used by CI. If we have helm charts, can the charts be used to generate yaml files so that they don't go out of sync?

yeah. You can run something like: 'helm template external-snapshotter > static.yaml' to generate them.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

I use helm chart 2.1.2 then I found that: old version of deployment can create crds(Related to volumesnapshot ) by them themselves.
Recently, our storage has been depleted, so we want to set up a new ceph cluster.

I found following questions:

• new csi-snapshotter will not apply a crd into cluster,
• and not any crds in helm chart.
• I found that new crds remove the support for v1alpha1.

Because crds of snapshotter not change so much, and there are not many new features, I think we can provide a conversion webhook help users smoothly deprecate versions.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

Yes, helm is more convenient for automation.

I agree that a Helm chart would be more convenient. Although I also see that maintaining a proper chart requires more resources. The charts provided by @WanzenBug work great btw.

resource "helm_release" "webhook" {
  name       = "snapshot-validation-webhook"
  chart      = "snapshot-validation-webhook"
  repository = "https://piraeus.io/helm-charts/"
  version    = var.webhook_chart_version

  namespace        = local.namespace

  values = [yamlencode({
    nodeSelector = var.node_selector
  })]

  depends_on = [
    kubectl_manifest.crds,
  ]
}

resource "helm_release" "controller" {
  name       = "snapshot-controller"
  chart      = "snapshot-controller"
  repository = "https://piraeus.io/helm-charts/"
  version    = var.controller_chart_version

  namespace        = local.namespace

  values = [yamlencode({
    nodeSelector = var.node_selector
  })]

  depends_on = [
    kubectl_manifest.crds,
    helm_release.webhook,
  ]
}

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

@k8s-triage-robot: Closing this issue.