Helmfile: Summary of operations and results at the end

[cmeury]

When there is an error, one has to parse through the entire output to find out what went wrong. A summary of releases and their status (or even abbreviated error message) would help to quickly identify the problem.

[cmeury]

Salt's highstate output is a possible inspiration.

They also have the concepts of different output modules, which might be something to look into. But when looking at the k8s/Helm ecosystem, it's probably pretty-printed, JSON and YAML. Thoughts?

[mumoshu]

@cmeury Sounds awesome! Would you by any chance provide me an example input/output, so that we can understand how this feature would be designed/implemented?

[cmeury]

Running: helmfile -f helmfile-2.yaml --kube-context dev --summary

<long helmfile and helm output>

RELEASE          UPDATED                   RESULT    CHART           NAMESPACE
grafana          Wed Mar 14 23:41:00 2018  DEPLOYED  grafana-0.8.2   platform
traefik-ingress  Wed Mar 14 23:41:00 2018  FAILED    traefik-1.24.1  platform

Summary: helmfile-2.yaml | Context: dev | 1 of 2 successful (50%)

Running: helmfile -f helmfile-2.yaml --kube-context dev --quiet --summary

RELEASE          UPDATED                   RESULT    CHART           NAMESPACE
grafana          Wed Mar 14 23:41:00 2018  DEPLOYED  grafana-0.8.2   platform
traefik-ingress  Wed Mar 14 23:41:00 2018  FAILED    traefik-1.24.1  platform

Summary: helmfile-2.yaml | Context: dev | 1 of 2 successful (50%)

Running: helmfile -f helmfile-2.yaml --kube-context dev --quiet --summary --format json

{
  "summary": {
    "file": "helmfile-2.yaml",
    "context: "dev"
  },
   results: [
    {
      "release": "grafana"
...etc.

[mumoshu]

@sstarcher Similarly to what I asked you about the upcoming helmfile status feature, what kind of information would you like to see from helmfile sync? I appreciate your comment.

[sstarcher]

My overall opinion is to suppress all information unless --debug is set and to only output success/failure. On failure more information could be dumped as to why it failed.

I would lean toward on a successful update to only see something like.

blah upgrade suceeded
blah2 upgrade succeeded

Suppressing all secret description, etc ,etc unless a failure happens then the output should be supplied. So capture the output of a command and hold it incase of failure.

[mumoshu]

@sstarcher Makes sense to me 👍I think I'm also in favor of that pattern - for example I'd want the proposed helmfile lint to be verbose when and only when it failed.

Just to be extra clear, in contrast to the vanilla helmfile sync, the proposed helmfile sync --format json and helmfile status [-o json] should include all the information equivalent to the verbose mode for usability.

[mumoshu]

586 reduced verbose logs, and thanks to @sgandon #560 we now the summaries of deleted, updated, installed releases!

Thanks you all for your patience and support.

Closing this as finally resolved.