Rendering bug in 1.35.2

[eshepelyuk]

Hello

After updating to 1.35.2 - this code in values.yaml doesn't work anymore

hull:
  config:
    general:
      rbac: false
  objects:
    configmap:
      metadata:
        data:
          myKey:
            enabled: _HT? hasKey _HT*hull.config.specific "myKey"
            inline: _HT*hull.config.specific.myKey

with following error

create_deployments: error deploying default:  error executing 'helm template dashboard --values /tmp/875078234 --namespace nlx . --take-ownership --kube-context del/local': Error: execution error at (dashboard/templates/hull.yaml:1:4):
HULL failed with error HULL-GET-TRANSFORMATION-REFERENCE-INVALID: Element myKey in path hull.config.specific.myKey was not found

In version 1.35.1 the same values.yaml renders correctly, producing this

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app.kubernetes.io/component: default
    app.kubernetes.io/instance: dashboard
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: dashboard
    app.kubernetes.io/part-of: undefined
    app.kubernetes.io/version: 0.0.0
    helm.sh/chart: dashboard-0.0.0
  name: dashboard-dashboard-default
  namespace: nlx
---
# Source: dashboard/templates/hull.yaml
apiVersion: v1
data: {}
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/component: metadata
    app.kubernetes.io/instance: dashboard
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: dashboard
    app.kubernetes.io/part-of: undefined
    app.kubernetes.io/version: 0.0.0
    helm.sh/chart: dashboard-0.0.0
  name: dashboard-dashboard-metadata
  namespace: nlx

[gre9ory]

Sorry for the problem you are facing.

The tests did not flag such a problem when the changes for last release were made, but given your example I have a pretty good idea what is happening here.

With last release, a change was made to the HULL internal error handling.

Previously, if a HULL-related problem was detected during tree processing (eg. such an incorrect _HT* reference), a particularly formatted ERROR message was written to the rendered YAML output at the property value where the error occured. As a last step of chart processing, all rendered fields in the object trees were scanned and any errors in the field's values caused an overall installation failure.

Now the problem with that was, that any error, which popped up in fields that are not rendered in the final result objects, was basically dropped from sight and did not cause a overall failure in the end. So errors could go by "unnoticed".

So, to improve this and catch all problems, in the new release all detected errors are not written to the YAML field where they occured but instead in a dedicated (hidden) list field in the YAML tree. Instead of parsing all of the rendered objects for errors at the end, only the dedicated array containing potential errors needs checking for errors to raise. No errors are "unnoticed" this way.

In your case this causes the problem. If enabled resolves to false, the whole object content (including the under this condition broken _HT* reference) was not rendered previously and so the "error" in the object definition does not bubble up. In the new release, the reference error is always collected in the separate list and hence does not get lost and fails the installation.

Hope you can follow the explanation.

I do see the point in what you are doing and will think about a solution. First thought is to try dropping errors that occur in enabled: false object instances, will think about whether this option is the right way forward. If it does not work out, dropping the new behavior again is an option if it causes unintended harm more than it helps. I suspect your other new issue to be related to the same cause.

Meanwhile if you can, please not use 1.35.2 for now until a solution is found. Thanks!