Add Helm Chart manifests and GitHub Release Helm Chart for the snapshot-controller component

[kaskol10]

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

/kind api-change
/kind bug
/kind cleanup
/kind design
/kind documentation
/kind failing-test
/kind feature
/kind flake

/kind design

What this PR does / why we need it:

The changes introduced with this PR allow for better integration snapshot-controller and Helm. Besides, publish the Helm Chart in the GitHub Releases Pages using a GitHub Action.

Which issue(s) this PR fixes:

Fixes #551

Special notes for your reviewer:
A GitHub branch called gh-pages would be needed to store the published charts. It's a pre-requisite for chart-releaser-action
Does this PR introduce a user-facing change?:

Added Helm Chart manifests and Helm Chart GitHub Release for snapshot-controller component

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Ramiro Alvarez Fernandez (afd2861, ae977de, c3a8271)

[k8s-ci-robot]

Welcome @kaskol10!

It looks like this is your first PR to kubernetes-csi/external-snapshotter 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-csi/external-snapshotter has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @kaskol10. Thanks for your PR.

I'm waiting for a kubernetes-csi member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[kaskol10]

/assign @msau42

[z0rc]

Please include CRDs into chart as well.

[SamuelBagattin]

Please include CRDs into chart as well.

According to stevehipwell, is it really a good practice to install CRDs part of a helm chart ?

[z0rc]

@SamuelBagattin Helm isn't able to manage full lifecycle of CRDs, that's true, but it is quite capable of installing CRDs if there is none. Which solves initial deployment task. It's common practice on CRDs change to bump major chart version and provide instructions how to update CRDs, check out https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack.

[eumel8]

Great work, @kaskol10 , many thanks!
Any progress here on this PR? In the past we had our own Helm chart for CRDs, before the snapshot controller manager was removed from OpenStack Cinder CSI Chart and it's not available anymore since openstack-cinder-csi-2.0.0. Would be a good idea to have a fast replacements, thx!

[SamuelBagattin]

Hi @kaskol10 🙌
It's been a while there has been no more commit on this PR, and the helm chart would really help us 😊
Any update ?

[ggriffiths]

/ok-to-test

[ggriffiths]

My concern with this is continued support of helm charts by the maintainers, I am not sure if that's something the team would have the bandwidth to do for every release. I'll defer to @xing-yang as to if we want to continue maintaining helm charts for the snapshot-controller in this repo.

[xing-yang]

My concern with this is continued support of helm charts by the maintainers, I am not sure if that's something the team would have the bandwidth to do for every release. I'll defer to @xing-yang as to if we want to continue maintaining helm charts for the snapshot-controller in this repo.

Thanks @kaskol10 for your contribution. As mentioned by @ggriffiths, that's exactly the concern we have.

[KlavsKlavsen]

We too would really like an easy way to actually install this.. What other way do you recommend, instead of using a Helm Chart?

[ggriffiths]

We too would really like an easy way to actually install this.. What other way do you recommend, instead of using a Helm Chart?

The deployment files under deploy/kubernetes will work. We maintain those for every release with new flags/RBAC/etc.

If there's enough interest, maybe you can create a separate repo to house and maintain the Helm installation.

[sathieu]

My concern with this is continued support of helm charts by the maintainers,

Maybe the solution is to generate the plain manifests from the helm chart (and add a pipeline to ensure. WDYT?

NB: there is also helmify to create charts from plain manifests.

[sathieu]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages 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 PR is closed

You can:

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

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

/lifecycle stale

[kahirokunn]

Keep

[Nuru]

/remove-lifecycle stale

I would use a Helm chart if one were available.

[KlavsKlavsen]

One maybe overlooked feature of using helm charts - is that they make it MUCH easier to automate monitoring for version updates, in a standardized way. We actually just have a script that looks through all our application helm charts (from upstream) - and talks to helm repo - to see if a new version exists.. Making it work pretty much like good old Linux repos - for k8s.

[z0rc]

Everyone who still comments here. Have you seen https://github.com/piraeusdatastore/helm-charts/tree/main/charts/snapshot-controller? It was linked here at #622 (comment). Have you tried it? Is it missing something? There is already existing fully functional helm chart available.

[KlavsKlavsen]

We are following the piraus charts - but IMHO its important that charts are "maintained alongside the code it installs" - as any other "release package". Thats the learnings from Helms "once upon a time - central package repository" - which was discontinues because things bitrot, when they don't live together.
The install guide of this project SHOULD list the helm chart - and frankly I don't understand the hesitance to do so, when helm packages has such a huge advantage over "raw yaml" - for the users of the project (making k8s app maintenance much easier to do - as automation for monitoring for updates etc. . is made so much easier).

[z0rc]

I don't buy it. History of "central package repository" doesn't have anything to do with this case. Instead Helm enables anyone to package some manifests in a way they want to and distribute them. Project maintainers aren't obliged to provide a helm chart. This project isn't a unique case of not providing charts. Instead we see a raise of 3rd party repos that package multiple different projects (like https://github.com/bitnami/charts/tree/main/bitnami or https://github.com/deliveryhero/helm-charts/tree/master/stable), which is a good thing as this offloads burden from project maintainers and actually reduces chance of bitrot.

[KlavsKlavsen]

No one said they were obliged. Its simply one of the best ways to consume k8s apps for the users, as it has features that enables easy monitoring for new versions f.ex. - instead of having to manually crawl through 50+ app repos (or how many you end up using), to check for updates regulary :)
If its a 3rd party, which true - some are - one has to be a bit more careful - and also watch out for "helm chart not being updated/following upstream anymore".

This is why f.ex. Ubuntu package a lot of applications into their repos - as Ubuntu users, then easily can follow updates and trust they're of decent quality and up2date.

With k8s there aren't really distros in the same way, so you follow the apps you choose to use - and Helm really makes that easier, and also allows for applications to "simplify" install options, via the templating and values features of Helm.

We're using it in our open source project https://github.com/Obmondo/k8id/tree/master/argocd-helm-charts/external-snapshotter - to f.ex. allow specifying multiple helm charts that needs to be installed to have a working external-snapshotter setup - trying to make everyones life easier, operating k8s :)

[k8s-ci-robot]

@kaskol10: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-kubernetes-csi-external-snapshotter-1-27-on-kubernetes-1-27	5aebed5	link	true	/test pull-kubernetes-csi-external-snapshotter-1-27-on-kubernetes-1-27

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[vstthomas]

It was not readily apparent to my HOW to implement this. For anyone that comes after; I just installed like this:

module "eks_blueprints_addons" {
  source  = "aws-ia/eks-blueprints-addons/aws"
  version = "~> 1.12.0" #ensure to update this to the latest/desired version

  # Any addon from "add-ons from Amazon EKS" can be added to the below block
  # https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html#workloads-add-ons-available-eks
  eks_addons = {
    aws-ebs-csi-driver = {
      most_recent              = true
      service_account_role_arn = module.ebs_csi_driver_irsa.iam_role_arn
    }
    snapshot-controller = {
      most_recent = true
    }
  }
...
}

I hope this helps the next person 😄

[k8s-triage-robot]

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

This bot triages 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 PR is closed

You can:

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

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

/lifecycle stale

[kahirokunn]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages 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 PR is closed

You can:

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

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages 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 PR is closed

You can:

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

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

/lifecycle rotten

[Nuru]

/remove-lifecycle rotten

I'd still like to see this and would use it if it were available

[k8s-triage-robot]

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

This bot triages 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 PR is closed

You can:

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

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

/lifecycle stale

[pschichtel]

/remove-lifecycle stale