Templating error: did not find expected key - improve error messages

[pikrzysztof]

-> % kubecrt chart.yml
yaml: line 36: did not find expected key
charts config parsing error: 

 1: 
 2: # apiVersion defines the version of the charts.yaml structure. Currently,
 3: # only "v1" is supported.
 4: apiVersion: v1
 5: 
 6: # name is the .Release.Name template value that charts can use in their
 7: # templates, which can be overridden by the "--name" CLI flag. If omitted,
 8: # "--name" is required.
 9: name: loki
10: 
11: # namespace is the .Release.Namespace template value that charts can use in
12: # their templates. Note that since kubecrt does not communicate with
13: # Kubernetes in any way, it is up to you to also use this namespace when
14: # doing kubectl apply [...]. Can be overridden using "--namespace".  If omitted,
15: # "--namespace" is required.
16: namespace: prometheus
17: 
18: # charts is an array of charts you want to compile into Kubernetes resource
19: # files.
20: #
21: # A single chart might be used to deploy something simple, like a memcached pod,
22: # or something complex, like a full web app stack with HTTP servers, databases,
23: # caches, and so on.
24: charts:
25: 
26: # A Chart can either be in the format REPO/NAME, or a PATH to a local chart.
27: #
28: # If using REPO/NAME, kubecrt knows by-default where to locate the "stable"
29: # repository, all other repositories require the "repo" configuration (see
30: # below).
31: - "/home/kris/PycharmProjects/loki/production/helm/loki-stack/Chart.yaml"
32: 
33:     # values is a map of key/value pairs used when compiling the chart. This
34:     # uses the same format as in regular chart "values.yaml" files.
35:     #
36:     # see: https://git.io/v9Tyr
37:     values:
38:       loki:
39:         enabled: true
40:       promtail:
41:         enabled: true
42:       grafana:
43:         enabled: false
44:         sidecar:
45:           datasources:
46:             enabled: true
47:       image:
48:         tag: 6.3.0-beta2
49: 
50:     prometheus:
51:       enabled: false
52:       server:
53:         fullnameOverride: prometheus-server
54: 
55:         requests:
56:           memory: 1024Mi
57:           cpu: 750m
58:         # charts.yaml supports the same templating as chart templates do,
59:         # using the "sprig" library.
60:         #
61:         # see: https://masterminds.github.io/sprig/
62: 
63: 
64: # For the above charts, see here for the default configurations:
65: #
66: #   * stable/factorio: https://git.io/v9Tyr
67: #   * stable/minecraft: https://git.io/v9Tya
68: #   * opsgoodness/prometheus-operator: https://git.io/v9SAY

33:     # values is a map of key/value pairs used when compiling the chart. This
34:     # uses the same format as in regular chart "values.yaml" files.
35:     #
36:     # see: https://git.io/v9Tyr
37:     values:
38:       loki:
39:         enabled: true

Templating error: did not find expected key

This is my first time using this tool. I'd like to know what went wrong, which variable was unset or what key was expected and where. The error message highlights line 36 which is a comment so I guess it's about line 37?

[JeanMertz]

Hey @pikrzysztof, thank you for the report.

Indeed, I suspect the line numbers are off-by-one 🙈, we'll get that fixed.

As for the actual problem you are running into, it looks like your indentation is a bit off. YAML is whitespace sensitive (similar to Python), so if you indent too much, or not enough, you'll get these kinds of errors.

In this case, it looks like values on line 37 is indented with 4 spaces, instead of 2. I suspect if you de-indent lines 37 to 48 by 2 spaces, things should work as expected.

[pikrzysztof]

Thank you for your prompt response. I'd love to see kubecrt tell me what was expected and what exactly failed without raising a ticket.

[JeanMertz]

That's a fair point @pikrzysztof. Right now, Kubecrt is a thin wrapper around the Go YAML and Helm packages, and any errors they report are bubbled up as output of the CLI.

In this case, the error you see is from the YAML package.

If we wanted to improve this message, we would have to write our own parser or switch to another library with more sophisticated error messages (if any exist). I don't see either of the two happening anytime soon, unless anyone wants to contribute, so unfortunately we'll have to accept the status quo.

Feel free to comment with any other issue you run into that isn't easy to debug though. Even though we might not be able to improve the error message right now, at least having an archive of issues to search through will help anyone running into this in the future.