Skip to content
This repository has been archived by the owner on Jun 25, 2021. It is now read-only.

Latest commit

 

History

History
82 lines (58 loc) · 4.2 KB

Round1_Table2_Future_of_Charts.md

File metadata and controls

82 lines (58 loc) · 4.2 KB
Raw

Table of Contents

Future of Helm Charts

Topic 1: Should repositories like ChartMuseum signal quality?

For users, it was agreed that it is useful to have some sort of signalling mechanism for quality. There were various proposals made to signal quality of charts – each had its benefits and drawbacks.

Ratings

  • There are certain problems that arise with using ratings as a quality signalling mechanism
    • The system can be gamed, folks can ask friends / colleagues to rate things, often means nothing about the actual quality.
    • Ratings don't work well over a period of time. For eg. if there is a chart with bad ratings, that gets fixed, the bad ratings still persist. Idea - rate every version seperately.
  • Maybe something along the style of Amazon reviews is better than ratings? But then again, this can be gamed – see fake Amazon reviews.

Number of Downloads

  • How do you know that downloads have been by an actual user vs. something like a CI system?
  • kubeapps hub pulls all of the charts – how do you distinguish that from a real person?
  • Any information can be gamed – however if you have a million downloads / docker pulls, there is definitely a message there – people are finding the chart / image useful!
  • Recently Helm added user agent flags – maybe we can use something like this to differentiate from CI? This is worth a follow up.

However, with either of these two options, where is the correct place to store any such info about downloads? Does this belong in the chart repository?

  • Big orgs prefer to use on-premise tools. They need some way of sharing knowledge. Would they need something like this? Might be overkill for them though.

Topic 2: Changing the format of the chart index to be more performant .

  • Upstream issue filed for this – Issue 3557: helm/helm#3557
  • The original repository file format was based on Debian
    • It was anticipated that someday we'll reach a scale where we will run into performance issues.
  • If someone wants to propose and move to a v2 repository file format this would be a good contribution
    • There was a talk from Ankur Chadha (JFrog) that kicked off discussion here.
  • Will moving to a new v2 repository format be a breaking change for search?
    • Helm search should still work even with this move
  • A problem this would solve for the chart repo - have a distributed index / chart delegation (viglesias).
    • This would make charts a sort of meta-repo, so kubernetes/charts can have something that it can delegate to instead of growing unsustainably.

Topic 3: Upload of charts directly from the helm CLI

  • It might make sense for the chart upload mechanism to be based on Helm plugins
    • The plugin interface is confusing today, can we make this better / easier?
    • Also discovery and downloading the plugins can be problematic (today at least).
    • Moreover, kubectl has its own plugins and plugin mechanisms
    • (Completely different side topic – Should helm be/have a kubectl plugin interface?)
  • It was mentioned that the plugin conversation is not simple – need to follow up with what conversations happend at the plugin table during the Summit (which was a later session).
  • Should "helm push" be added to the base API and not be a plugin? This is a bigger conversation. At the very least this deserves an issue in the Helm issue queue, where folks can weigh in on the idea.