Charts: [stable/locust] Chart not useful in current form - should there be a usefulness requirement for stable charts?

Created on 22 Oct 2017 · 15Comments · Source: helm/charts

I'll prefix this by saying that I might have missed something really obvious about Helm, but I've been reading docs and searching extensively for the past few hours and I've come up empty.

I guess this is part of a broader discussion around the purpose of this repo; namely, should charts be useful?

Is this a request for help?: No, unless I'm missing something...

Is this a BUG REPORT or FEATURE REQUEST? (choose one): Feature request? Open discussion?

Which chart: Specifically stable/locust but I've seen a similar issue with other charts.

The chart installs and runs with the default, bundled configuration but is absolutely useless because the behaviour of the packaged application is defined by files that are built into a ConfigMap and installed as part of the chart, when the whole point of the application is for the user to define their own behaviour via Python.

The only options that I can find for making the chart useful are:

Maintain my own copy of the chart in a fork of this repo, which seems to defeat the purpose of Helm as a package manager,
Create a subchart which removes and replaces the configMap with my own version, which seems hacky and could mess with upgrades, or
Remove and replace the configMap on the cluster after installation which will definitely break after upgrades.

In my opinion, charts that make it to "stable" status should not just run, but also be able to support useful baseline functionality of the applications they install - otherwise what's the point?

Again, if I've missed something obvious, I apologise and would welcome a pointer in the right direction. :)

lifecyclrotten lifecyclstale

Source

dfcowell

👍9

Most helpful comment

Right, the files holding the Python scripts are part of the chart and I see now this only works when forked, I will look into making this more generic as this chart was created a Long time ago. Thanks for tagging me as I was not aware of any issues

so0k on 7 Mar 2018

🎉5

All 15 comments

Yeh I don't get this at all. Did you ever find a solution @dfcowell ?

adamresson on 19 Jan 2018

I used the templates to produce my own manifests manually. After many cases
like this I'm very tempted to fork the repo and maintain my own charts,
bringing them in line with a usefulness standard on an as-I-need-it basis.

It seems like the Kubernetes charts project is more interested in ticking
boxes than providing actual utility, which is unfortunate.

Another issue I have is with bad legacy implementations (Deployments
instead of StatefulSets or DaemonSets) but that's another issue entirely.

On 19 Jan. 2018 20:46, "adamresson" notifications@github.com wrote:

Yeh I don't get this at all. Did you ever find a solution @dfcowell
https://github.com/dfcowell ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/charts/issues/2560#issuecomment-358970153,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPGEt2ZuODepaaU2uV-R0wM76ff07FNks5tMJy_gaJpZM4QCC49
.

dfcowell on 19 Jan 2018

Just checking if anyone has an update on how they implemented the functionality this chart should provide? @dfcowell @adamresson

I'm currently planning to see if I can make this useful and PR it or, failing that, to copy this over to my own repo and modify the tasks as needed.

Perhaps the original author, @so0k, can provide some further insight on this issue?

Cheers

rdkr on 7 Mar 2018

What is blocking you?

so0k on 7 Mar 2018

Oh, I see, I'll read through this

so0k on 7 Mar 2018

🎉5

I'd need to base off https://github.com/kubernetes/charts/pull/3288 I assume @haad @jdumars @unguiculus

so0k on 13 Mar 2018

Yes that would be perfect.

haad on 13 Mar 2018

After internal discussion within Honestbee, @joerx and I agree it would make more sense if the Locust tasks are part of the image provided by the user and not in a configmap.

The way forward seems simply to remove the configmap (or make a configmap reference optional and external to the chart)

so0k on 20 Mar 2018

Personally my suggestion would be to ask for a configmap name which gets merged into the chart.

From there, people wanting to use the chart could just create their own configmap and reference it by name in values.yml when installing the chart.

That might be what you're talking about?

dfcowell on 20 Mar 2018

👍2

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot on 18 Jun 2018

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

fejta-bot on 18 Jul 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

stale[bot] on 19 Aug 2018

This issue is being automatically closed due to inactivity.

stale[bot] on 2 Sep 2018

The suggestion from @dfcowell would make sense to me as it would be in line with other charts such as how the keycloak chart allows a custom realm to be referenced. Would be great to get this reopened as there is demand to address this - https://stackoverflow.com/questions/53932412/how-to-integrate-custom-scripts-into-locust-helm-chart-stable-locust