-
Notifications
You must be signed in to change notification settings - Fork 486
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Second attempt to host a Helm chart #1062
Comments
Thank you for providing and maintaining the Helm chart in the past years. I understand that times change and tusd might not be so relevant for you anymore. We would be more than happy to move the Helm chart into this organization to ensure that your contributions can continue to be used and developed. That being said, we are still no Helm users, so we will also be relying on external contributors, but that's OK. Regarding the two options, I am currently favoring including it in this repository. We include the Docker image also in this repository and don't have a separate one, so it would make sense to put the Helm chart here as well. In addition, I am worried that if we have two separate repositories, it will make releases more complicated as we also have to remember to update the tusd version in the Helm chart. Ideally, we could extend the release mechanism in this repository to generate a Helm for each release, just like we do for the binary builds and the Docker images. |
@Acconut thanks for the reply! I have some other projects where a Helm chart is being released from the same project, so I have some existing GHA workflows that I can port alongside with the Helm chart.
I'm happy to help with reviews as much as my free time allows. Looking at past contributions in my own chart, people generally know what they are doing/asking for, so it's mostly just a sanity check. I'm gonna send a PR then in the coming weeks moving the current chart in this repo (under |
Great, I am looking forward to it!
Would it make sense to move into a shared folder with some of the Docker-stuff we have? Maybe we can put them into a common folder |
IMO Docker is build stuff, Helm is deploy stuff |
Alright, then let's go with the usual path for now. We can always move it somewhere else in the repo later :) |
Hello!
I attempted to add a Helm chart to this repo a couple years back in #324
The resolution back then was me publishing the Helm chart in my personal Helm repo.
A few things have changed since then, so I thought I'd make another attempt to suggest hosting a Helm chart in the official Tus organization.
First of all, OCI support became stable in Helm and GitHub has ghcr.io now to host not just container images, but Helm charts as well. This approach makes publishing Helm charts way easier compared to having to run a Helm chart repo (or publishing one on GitHub pages)
Secondly, I don't use Tus that actively these days, so I feel like I became a blocker in the charts maintenance. At the same time, the fact that it's hosted in my personal repo makes it harder to add other contributors.
For those reasons, I'd like to put a few proposals on the table for your consideration:
One option would be to add the helm chart to this repo. The chart testing and publishing workflow would become a single GHA workflow and the chart could be hosted on ghcr.io (eg.
ghcr.io/tus/helm-charts/tusd
). A common pattern is to add deployment related resources to adeploy
directory.The only downside of this option is that adding external contributors is relatively harder (compared to the second option)
The second option is creating a separate repo (eg.
tusd-helm
) to make adding external contributors easier.Given these are acceptable options for you, I'd be happy to spend some time on migrating my existing chart to another location, write some docs for contrib, etc.
Last time, the decision was largely based on the fact the core maintainers do not use Kubernetes therefore, they felt hosting the chart here would send the wrong message to the community. Given the above, I believe that with enough involvement from the community we can make this work, but I understand if you still feel the same way about it. I just thought it would make sense to raise the question again.
Thanks!
The text was updated successfully, but these errors were encountered: