Q: helmfile under Helm org / CNCF?
naseemkullah opened this issue · 27 comments
Would it be beneficial to have helmfile governed by the CNCF?
If so application details are here: https://github.com/cncf/toc/blob/master/process/project_proposals.adoc
@naseemkullah I've considered it before and I do think doing so will provide helmfile users additional evidence of reliability.
But why do you want helmfile maintained under CNCF, anyway?
I think it would help foster more community around this high quality project and I feel there is a void for a project that solves this problem (declaring helm releases) in the CNCF ecosystem. My 2 cents.
Feel free to close this issue! I was just curious if you had considered it.
Thanks!
I do want to propose helmfile to CNCF. The primary blocker for it is that, to me, its priority is lower than addressing all the queued feature requests, answering questions, doing experiments like helmfile-operator.
That being said, please let me keep this open so that (hopefully) someone chimes in to write up a CNCF proposal, and/or become a sponsor(Perhaps we need a privileged sponsor to be accepted as a CNCF project?)
helmfile is a great way to deploy helm charts. I hope that this project will grow and mature. That sad i don't think it is really need to become CNCF project per say. IMHO it would be good to make helmfile as part of helm or under helm umbrella so it would be considered as part of helm 3 and covered with tests. Would be great if this can be discussed with @technosophos at Helm Summit. Of course if this will benefit to project and if it's a good timing
The Helm org is set up to host other subprojects like chartmuseum and monocular. So it's certainly something the Helm org maintainers would be open to if you decide to go that way.
@archyufa @technosophos I'd like to the original author of helmfile @roboll to confirm it, but anyway - I believe it's awesome for Helmfile to be hosted under the Helm org!
Does the Helm org. define a proposal process? I'd be happy if you could share it so that I can write docs(if needed) and prepare for further discussions.
I see two existing proposals in the community repo https://github.com/helm/community/tree/master/proposals
Shall I submit a PR to add a proposal for helmfile? If so, I'd include helmfile's history, vision, goals and plans in the proposal - Please let me know if anything needs to be added.
What is the argument in favor of moving the project?
What benefits does moving under the Helm umbrella provide?
Personally I don't see any reason to approach CNCF about this; the project isn't in need of support or governance.
@roboll I think we need more arguments!
Probably @naseemkullah could add something from a more user-centric view.
From a maintainer's perspective, I have only two benefits in my mind to move this project:
- Long-term maintenance of Helmfile
- Raising the bar while helping other projects in the ecosystem
And I'd prefer moving to Helm for now. Details follow. Any feedback is welcomed.
Long-term maintenance of Helmfile
We have users and I just want keep Helmfile maintained longer for users. I believe increasing velocity is one of the ways to keep the project maintained longer. I expect that moving to CNCF or Helm increases the project's velocity and results in the project maintained longer.
Increased velocity means we are able to put more resources on user-support, bug fixes, developing features. Things like great governance, tooling, maintainers all increase velocity.
By moving the project under a umbrella like CNCF or Helm, I'd expect the project's visibility increased, attracting more users, and potential maintainers(this may include my added time to work on the project sponsored by my employer), that contributes to velocity, that results in a more reliable and useful tool(helmfile), that attracts more users, repeat. In that sense moving the project to either CNCF or Helm is beneficial.
Also, I think both projects has their own governance and tooling, which may help Helmfile's development - additional velocity.
A potential benefit of Helm over CNCF is possibility to work more closely with the entire Helm project for increased velocity, like adding E2E tests with Helmfile to Helm. A little more velocity added.
Raising the bar while helping other projects
My goal for Helmfile is making it super easy to deploy complex apps everywhere. Whatever is okay as long as the goal is achieved.
I have no desire to make Helmfile the only "winner" in this area. But I DO like someone in the world provides a great alternative to Helmfile if it becomes outdated and unmaintained someday.
I was attracted and have been maintaining Helmfile because the declarative spec for complex apps on top of helm and k8s seemed both practical and effective path towards the goal. Helmfile is great. But you'll see many interesting issues still open to be addressed. And the Helm use-cases explored by Helmfile are not very reusable at the moment by other projects.
On the other hand, I'm not feeling very happy about a bunch of tools, projects, vendors, services reinventing what's already done with Helm(packaging and basic release management) and Helmfile.
By moving the project to Helm, I'm hoping that we can collaborate more closely making Helm reusable (as a go library, for example) for easier consumption by projects like Helmfile, while making Helmfile itself a reference implementation of declarative app deplyoment tool that integrates nicely with Helm and feature-rich, resolving the interesting issues. Both efforts will eventually be inherited to a bunch of tools/projects/etc, that contributes to the goal.
I believe all these things can "technically" be achieved without moving the project, as (I think) Helmfile is already well maintained.
But the reality is we're a small team with no vendor behind it, very limited resources.
So I got to think about paying forward while we're still alive. That is to gain more velocity and communication to produce the momentum to keep the project going further, by moving the project under a umbrella.
To be clear, I don't know whether my thoughts align well with the acceptance criteria of the CNCF or the Helm org. What's why I asked about the proposal process.
What is the argument in favor of moving the project?
What benefits does moving under the Helm umbrella provide?
Personally I don't see any reason to approach CNCF about this; the project isn't in need of support or governance.
First off @roboll thank you for creating this amazing project.
You are technically correct the project is currently doing great thanks to @mumoshu who is resolving issues and contributing at a very high rate.
While @mumoshu already listed 2 of the main benefits, from a user endpoint, it's always a little more reassuring when an OSS project is hosted under an org/company rather than an individual's repo.
+1 for having in under Helm project
In terms of getting project under CNCF is really beneficial, however it's not easy to get project in as it requires finding a sponsor from TOC. Helm is already Graduated CNCF project, so helmfile will gain all benefit that CNCF project has.
From cons side joining helm project could be a larger wish list and potentially addition of many use cases that initial team didn't plan to have. (It will be harder control project destiny and taking some decision). This will really goon the way of how governance is set.
At this point I would really encourage to start discussion, especially in context of helm 3. It could be done at Helm summit (might be not possible due to travel requirements) as WG or just have a call with Helm maintainers (@rimusz, @technosophos please comment if you have any advise) and get all questions answered and what is the gaps. Than plan when is the best time to bring project under umbrella if it is decided at all.
Cert-manager project that I strongly believe in similar state perhaps @munnerz can provide his feedback on cons side to joining?
I think the biggest benefit of being part of the Helm organisation is providing reassurance to enterprise users, especially decision makers, that it's safe to embrace helmfile as part of production workflows, and it's not going to suddenly become an orphaned project. When I first suggested using it internally there were lots of questions about is this going to work long-term, what happens if the project gets abandonned, are we better off sticking with shell scripts, etc.
It's clear to myself and others who follow this project that @roboll and @mumoshu have done a great job in developing this tool, but to any newcomers it's "just another K8s tool on GitHub" and with the proliferation of k8s utilities it takes time to evaluate which projects have a long-term future with good community support and which are just experimental utilities. Being part of an organisation like Helm shows it's the former.
To help clear some things up-
There are already a couple subprojects under the helm/ org with 1 or 2 core maintainers (chart-testing, chartmuseum, etc). If moved, the maintainers of this project are encouraged to operate the repo as they have been, with no loss of control for the project's direction. Of course, we would love to work together and align on how all these tools might interconnect for benefit to end users.
There are only minor "legal" type requirements as a result of the move, such as contributors required to sign a Linux Foundation DCO, adopt Apache2 license, etc. If you decide to do so, you can work with the Helm org/maintainers directly, no need to involve the CNCF.
I agree it would make sense under the Helm org, no need to apply to CNCF directly.
@roboll the main benefit I see to your project maintainers is closer collaboration with the Helm project for issues related to security, communication, etc. The main benefit I see to users is trust.
@mumoshu The process is outlined in the governance doc too. If the current maintainer(s) agree - I believe that's @roboll - then the Helm org maintainers vote on it. Once a project is part of the Helm org, the project itself is largely governed by the project maintainers which you (@roboll ) would need to decide on.
@scottrigby I understood that the vote happens in the helm mailing-list. Am I correct? Then I'll start writing a proposal email for the vote, so that everyone(especially @roboll who's the author of this project) in this thread can react/iterate on.
That sounds like a good way to start
@mumoshu Please proceed with your mailing list proposal - we can discuss on Slack before getting the ball rolling. You've been doing the heavy lifting on this for a while, so I'll mostly leave it to you to to run with the proposal process.
Are we still moving forward with helmfile under the helm org?
@naseemkullah Yeah I'm willing to. It's just that I'm so busy triaging issues and working on various enhancements on Helmfile, therefore no much time to write the proposal.
Just to add my two cents to this...
Having Helmfile within the Helm ecosystem would be immensely beneficial in terms of perception management. My organization is currently going through a process of joining the CNCF as members and with that comes an increased onus and excitement for participating within the ecosystem. As an enterprise, this would mean that we treat organizations and their projects within the CNCF ecology as first-class citizens and it opens up access for teams like mine to champion it internally.
The umbrella project of Helm its requirements for usability, security and quality would become a forcing function to guide a roadmap that would help us orientate around the goals of Helm but accent that with the value provided by Helmfile.
I agree completely with @archyufa that it should be a careful consideration to join as there is a responsibility for maintenance and forward leadership. However, with a hoist in the visibility and wealth of highly active community members to contribute, I think the overall positives would be too good to ignore.
Is there a similar proposal from maybe chartmuseum or monocular I could follow? (will search myself) I'd be happy to draft something if that would help. I'm also willing to take a more active role in reviewing and testing merge requests and such. At least for now, we use this heavily throughout my organization, so it's a pretty high priority for me.
I'm not sure we did much in those cases other than an issue in github.com/community/helm that describes how you'd like to see the project run under the Helm org.
Can I ask you what is the status of this open issue?
I think it would be really really good to have helmfile under the Helm ecosystem
We do have an official document describing how Helmfile can become part of Helm: https://github.com/helm/community/blob/master/hips/hip-0003.md It was actually a direct result of this conversation. But I am not sure we've taken any new steps (on either side) since the HIP was approved in December 2020.
@AlexsJones perfectly summarized above the win-win situation resulting from Helmfile becoming part of Helm.
@mumoshu is it something you plan for a coming future? (we all know you are so busy with the so many improvements you are continiously adding to Helmfile so please do not understand my question as a way to ask you this to happen soon, not at all, it is only to know if you still see it as something to go for).
Thanks in advance.