external-snapshotter
external-snapshotter copied to clipboard
kubernetes-csi
Add Helm Chart manifests and GitHub Release Helm Chart for the snapshot-controller component
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
The committers are authorized under a signed CLA.
- :white_check_mark: Ramiro Alvarez Fernandez (afd2861adef544a73575371a0e4227598cbb3e18, ae977de2f8e968df8249dc76f52e3027c3fcd467, c3a82716a50cac26cd12b406f2aaf8e2a923fcda)
![linux-foundation-easycla[bot] avatar](https://avatars.githubusercontent.com/in/17893?v=4 "Published by a pub.dev verified publisher"){kind=small}
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. :smiley:
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.
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: kaskol10 To complete the pull request process, please ask for approval from msau42 after the PR has been reviewed.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
Please include CRDs into chart as well.
According to stevehipwell, is it really a good practice to install CRDs part of a helm chart ?
@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.
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!
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 ?
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.
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.
We too would really like an easy way to actually install this.. What other way do you recommend, instead of using a Helm Chart?
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.
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.
Just FYI, there are helm charts already available at https://github.com/piraeusdatastore/helm-charts. It's perfectly fine, if project maintainers don't want to support helm chart, helm community can help with existing chart maintained by 3rd party.
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.
How it's done isn't a concern, I just don't think there's enough contributor bandwidth to maintain that for every release. I would suggest setting up a community repo to maintain these charts.
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: kaskol10
Once this PR has been reviewed and has the lgtm label, please ask for approval from msau42 by writing /assign @msau42 in a comment. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
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.
Everyone who still comments here. Have you seen https://github.com/piraeusdatastore/helm-charts/tree/main/charts/snapshot-controller? It was linked here at https://github.com/kubernetes-csi/external-snapshotter/pull/622#issuecomment-1126292632. Have you tried it? Is it missing something? There is already existing fully functional helm chart available.
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).
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.