1. Cncf-Helm
  2. Topics

Helm stagnation or we're missing something?

Matt Farina
 

Dmitry,

I can add a little to what Adnan shared...

Helm tries to provide a semantic version guarantee to not break APIs on a major version. When the development from Helm v1 to Helm v2, which was mostly a re-write, there was a lot of development. After the 2.0.0 release there were new features until Helm v2 was in pretty good shape and Helm v2 was mostly seeing minor feature additions and bug fixes. Development slowed down naturally.

Open source projects, in general, go through different phases of activity. It can go up and down depending on what's going on. Helm had a peak during the Helm v2 major development and then it went into a valley. It's about to peak again at Helm v3 is being heavily invested in.

I can try to add some context to the issues brought up:

  • #3506 fixed a problem some of us needed to get fixed. There was a little pressure to get that fixed. Looking at the timing of the 3506, there was a 20 day gap between feedback and response to it. The alternative, that merged, was proposed and merged right about the same time that 3506 was responded to and made ready to go. I think it was more of a race condition to get one in. A change of a L or greater in size needs two helm core to approve and that happened on the alternative to 3506 first. I hope that helps understanding the why around them. There was definitely no ill will.
  • For #3481 the reason, I think, that bacongobbler tagged it was he supporting issue triaging. This is something core maintainers do. For me, I'm not sure how to quickly respond to it. I'd need to dig into the other work you linked off to as well as comparing what you want compared to the output with the `--debug` flag. Since I'm not working in that space I don't have the time to dig deeper and I'd hope for others to jump on this. A lack of response may mean others aren't working on the same problem space and otherwise busy. I know this can be frustrating. Have you reached out in slack or thought of coming to one of the helm developer calls to ask about it?
  • Helm tries to have good docs and examples so people can know how to use it. The Kubernetes community has talked about how insufficient docs is a problem for kubernetes as a whole. On #3540, I think it's reasonable to ask for those and then have a discussion. I would hope that when I made a new feature addition to helm 2 that someone would ask this of me. To hold me accountable.

This is all my 2 cents and an effort to add clarity. Contributions are appreciated and navigating the community interactions isn't always clean. Sorry for where it's messy.

Matt Farina
Adnan Abdulhussein
 

Hi Dmitry,

Thanks for reaching out. I can't speak for those issues and PRs in particular, but I wanted to make you aware that the Helm community is currently undergoing planning for Helm 3, and as such there are no major features being planned for Helm 2 releases.

Quite a few things are (possibly) set to change in Helm 3. For example, the server-side component (Tiller) is intended to be removed and possibly replaced by a Kubernetes controller. Release state will be stored as CRD objects.

Also, there are some new ideas around how hooks will work in Helm 3. Sounds like you're using hooks quite a bit, so it would be good to have you collaborate on the proposal to make sure what we do there will make sense in your workflow.

It's still early days in the planning, but if you'd like to get involved I encourage you to join the Thursday developer calls (https://github.com/kubernetes-helm/community/blob/master/communication.md#weekly-meeting).


On Wed, Mar 14, 2018 at 9:41 AM Dmitry Shurupov <dmitry.shurupov@...> wrote:
Dear community!

Helm is crucial in our software stack since we heavily use it in our own CI/CD workflow tool (sorry, we still have no English docs but we'll be improving that soon). It's so important that missing some features means real problems in some parts of our business. Luckily, Helm is Open Source, so we are happy to become a part of its community and share our improvements… however, that's where our issue appears. Almost all our attempts to bring some singificant (for us) updates end up not being really accepted.

Here are examples describing our general feeling:
1. https://github.com/kubernetes/helm/issues/3481 ­— that's our biggest disappointment as we've been doing a lot for logging, however there's no reaction since the very beginning of this issue. Does nobody need it? We are open to hear it — everything can be better than being totally uncertain.
2. https://github.com/kubernetes/helm/pull/3506 — this PR has appeared after we've seen not so successfull attempt to add "wait" feature to "helm init": that previous (not our) PR was accepted but didn't work actually and brought new problems to the code. So, we've decided to clean the code and fix this "wait". It seems developers (not so fast but anyway…) have liked our idea, however they have decided to rewrite everything by themselves. We could have done it also if they just asked us for that… Okay, so here are developers ready to spend their time for this minor thing. What about our next PR?
3. https://github.com/kubernetes/helm/pull/3540 — in this PR, we are requested to make docs + tutorial/example + tests while we haven't seen such requirements for other similar things (already existing policies). It's not we don't want to do it — it's just unexpected to observe this attitude here while minor issues are being rewritten by few developers. Is it only minor changes which are currently welcome in Helm?

If we add some public stats (https://github.com/kubernetes/helm/graphs/contributors) and check an overall scope of last PRs being merged (https://github.com/kubernetes/helm/pulls?q=is%3Apr+is%3Aclosed), it just strengthens our belief Helm is stagnating — at least, in public and especially, in contrast to Kubernetes itself. At the same time, it's the official package manager for K8s what makes us really care (and the whole community we hope?). We need some new features*, we are happy to implement them but we are blocked by core developers community of the project to pull (and, sometimes, even discuss) our changes. There can be another guess: some developers are actively working on a big new release of Helm with no real public signs of that (if so, it's not an Open Source way for sure).

Can anybody please shed us some light on what's really happening with Helm and what are the plans for its future? Maybe, all our "feeling" is totally irrelevant and we're doing something wrong?

* At least, we know one more important problem in Helm: isn't it strange to have a package manager which can't really check that the package has been installed successfully?


With sincere hopes to find some ways to work with community efficiently and make Helm better,

--
Dmitry Shurupov,

--
Adnan Abdulhussein
Software Engineer, Bitnami
+1 866 870 2383
@prydonius

Confidential - All Rights Reserved.
Bitnami (c) 2018
dmitry.shurupov@...
 

Dear community!

Helm is crucial in our software stack since we heavily use it in our own CI/CD workflow tool (sorry, we still have no English docs but we'll be improving that soon). It's so important that missing some features means real problems in some parts of our business. Luckily, Helm is Open Source, so we are happy to become a part of its community and share our improvements… however, that's where our issue appears. Almost all our attempts to bring some singificant (for us) updates end up not being really accepted.

Here are examples describing our general feeling:
1. https://github.com/kubernetes/helm/issues/3481 ­— that's our biggest disappointment as we've been doing a lot for logging, however there's no reaction since the very beginning of this issue. Does nobody need it? We are open to hear it — everything can be better than being totally uncertain.
2. https://github.com/kubernetes/helm/pull/3506 — this PR has appeared after we've seen not so successfull attempt to add "wait" feature to "helm init": that previous (not our) PR was accepted but didn't work actually and brought new problems to the code. So, we've decided to clean the code and fix this "wait". It seems developers (not so fast but anyway…) have liked our idea, however they have decided to rewrite everything by themselves. We could have done it also if they just asked us for that… Okay, so here are developers ready to spend their time for this minor thing. What about our next PR?
3. https://github.com/kubernetes/helm/pull/3540 — in this PR, we are requested to make docs + tutorial/example + tests while we haven't seen such requirements for other similar things (already existing policies). It's not we don't want to do it — it's just unexpected to observe this attitude here while minor issues are being rewritten by few developers. Is it only minor changes which are currently welcome in Helm?

If we add some public stats (https://github.com/kubernetes/helm/graphs/contributors) and check an overall scope of last PRs being merged (https://github.com/kubernetes/helm/pulls?q=is%3Apr+is%3Aclosed), it just strengthens our belief Helm is stagnating — at least, in public and especially, in contrast to Kubernetes itself. At the same time, it's the official package manager for K8s what makes us really care (and the whole community we hope?). We need some new features*, we are happy to implement them but we are blocked by core developers community of the project to pull (and, sometimes, even discuss) our changes. There can be another guess: some developers are actively working on a big new release of Helm with no real public signs of that (if so, it's not an Open Source way for sure).

Can anybody please shed us some light on what's really happening with Helm and what are the plans for its future? Maybe, all our "feeling" is totally irrelevant and we're doing something wrong?

* At least, we know one more important problem in Helm: isn't it strange to have a package manager which can't really check that the package has been installed successfully?


With sincere hopes to find some ways to work with community efficiently and make Helm better,

--
Dmitry Shurupov,
JSC "Flant"
http://flant.ru/
+7 (495) 721-10-27, add. 442

1 - 3 of 3