No error messages when accessing undefined variables in config templating

[mikn]

So, poking around in your settings system I noticed that the templates, both on the input from the user-data.toml and to the output in the templates, you use kebab-case, but in rust you use snake_case (few programming languages allow you to use kebab-case, I guess).

This took me an embarrassingly long time to figure out (I just assumed that since it was decoded into rust structs with snake_case, that the templating would use snake_case also).

Ultimately, what was not ergonomic in this was that I got no real error when trying to access template variables that does not exist and is not set. You do take great care to validate it in Rust, etc - perhaps there is a way to make sure that when accessing variables in the templating stage, that you check that the variable exists? Would have saved me a lot of time!

[cbgbt]

Hey @mikn, thanks for the report.

The template renderer is supposed to throw an error if we attempt to use a variable which isn't defined. We enable strict mode when constructing the template registry (relevant docs).

I wonder if we are rendering templates via a codepath that doesn't use these registry settings, or if these errors are not surfaced in a way that makes problems clear.

[cbgbt]

Yep, we don't use that codepath when we render template files in Bottlerocket.

Here's where we render templates, and that calls this function which does not use the registry code I linked above.

Phooey, I almost certainly introduced this regression when I last worked on schnauzer.

We can re-enable strict mode for these renderings, but we'll need to be very cautious in doing so -- it's a backwards incompatible change for core-kit. Existing templates which successfully render today could very well stop.

[mikn]

Ah! Nice that there is such a feature. The question that I get then is whether it is possible for me to activate it for my variant and my extensions even if you may be reluctant to reactivate it in the core-kit again?

[cbgbt]

I'm not sure there's a great way to do it right now without forking the template renderer schnauzer, but making it configurable seems reasonable and somewhat simple to accomplish. I'll chat with the team and make sure we can come to a consensus on that.

[cbgbt]

After looking into this more, I realized there are two different strict modes relating to template rendering, and I had mistaken the two.

• schnauzer strict mode -- This is the one that causes Handlebars templates to fail to render if a reference is made to an unset variable. This is currently unconfigurably set to true
• thar-be-settings strict mode -- thar-be-settings is the system that renders all of Bottlerocket's templates when settings are altered. The strict mode here determines if thar-be-settings fails if a sub-template fails to render, or if it proceeds with a warning. This is currently unconfigurably set to false.

Your issue makes it sound like you were anticipating behavior from the former strict mode, but didn't see it.

To my knowledge, there's currently one case where strict mode isn't respected for unset variables, and that's if you are using an if statement seeking truthiness from some value:

{{#if settings.some-thing }}
{{/if}}

In this case, settings.some-thing must be truthy, and it being un-set entirely (null) is treated as falsey, rather than causing a template to fail to render.

We could perhaps add another helper which is "stricter" on if statements, but we actually rely on the looseness of if in Bottlerocket currently.

Do you think you could provide more information on specifically what failed and how, so we can disambiguate which strict mode we should be thinking about here?

[mikn]

That's interesting - I guess this is where I should've written down more explicitly what I had done.
I had made a new configuration module called "kube-control", and I know that at least some of the problem I had was with certificates, which indeed follows the if pattern you mention. I however also had some files which did not have the if pattern for settings in kube-control. IIRC, I had named all variables with _ instead of -, but did not get a templating error during start of the server.

I do have configuration settings like these:

[configuration-files.apiserver-env]
path = "/etc/kubernetes/kube-apiserver/env"
template-path = "/usr/share/templates/control-plane/kube-apiserver-env"

where the env file that didn't fail looks like this:

[required-extensions]
kubernetes = "v1"
std = { version = "v1", helpers = ["base64_decode"] }
kube-control = "v1"
+++
APISERVER_ARGS="\
    --advertise-address={{settings.kube-control.advertise-address}} \
    --allow-privileged=true \
    --anonymous-auth=false \
    --authorization-mode=Node,RBAC \
    --bind-address={{settings.kube-control.external-bind-address}} \
    --client-ca-file=/etc/kubernetes/pki/ca.crt \
    --enable-bootstrap-token-auth=false \
    --etcd-servers={{settings.kube-control.etcd-servers}} \
    --etcd-cafile=/etc/kubernetes/pki/etcd-ca.crt \
    --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt \
    --etcd-prefix={{settings.kube-control.etcd-prefix}} \
    --external-hostname={{settings.kube-control.api-external-hostname}} \
    --kubelet-certificate-authority=/etc/kubernetes/pki/ca.crt \
    --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt \
    --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS \
    --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt \
    --requestheader-allowed-names=front-proxy-client \
    --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt \
    --requestheader-extra-headers-prefix=X-Remote-Extra- \
    --requestheader-group-headers=X-Remote-Group \
    --requestheader-username-headers=X-Remote-User \
    {{#if settings.kube-control.profiling}}
    --profiling=true \
    --contention-profiling=true \
    {{else}}
    --profiling=false \
    --contention-profiling=false \
    {{/if}}
    --permit-address-sharing \
    --secure-port=6443 \
    --service-account-extend-token-expiration=false \
    --service-account-issuer={{settings.kube-control.service-account-issuer}} \
    --service-account-key-file=/etc/kubernetes/pki/sa.pub \
    --service-account-max-token-expiration=2h \
    --service-cluster-ip-range={{settings.kube-control.service-cluster-ip-range}} \
    --tls-cert-file=/etc/kubernetes/pki/apiserver.crt \
    --tls-min-version=VersionTLS13 \
{{#if settings.kube-control.feature-gates}}
    --feature-gates={{join "," settings.kube-control.feature-gates}} \
{{/if}}
    --v=2" 

Where you can see a mixture of if wrapped settings and bare settings.

I must admit that I, despite your message, cannot quite understand whether this is schnauzer or thar-be-settings.