Comment 2 for bug 1881925

I think it's a little more complex than just wiring up. Schema validation doesn't only happen on systems which are the target for the cloud-config being validated (e.g. I could want to validate a schema which uses Azure-specific substitutions on my local (obviously-non-Azure) machine). And, more strongly than that, schema validation doesn't even only happen on systems where cloud-init has run or is installed (my dev machine doesn't have cloud-init installed). So we cannot assume that there will be any cloud-init data to substitute in and even if there _is_, we cannot assume that it is appropriate for use in the given cloud-config template.

As far as our schema is concerned, the specific values aren't important, it's just the types of the values that matter. So we can solve this by producing fake values for the variables in the template somehow. (We'll need to think about types a bit, but this isn't unachievable by any means.)

But we still have a problem: templates can have control flow. So a Jinja2 template can actually produce _structurally_ different cloud-configs, depending on the inputs to it. And, of course, the structure of cloud-config _is_ what the schema validates. I don't really have a great idea on how to handle this problem. That said, I think this applies to a small proportion of templates, so it's still absolutely worth enabling validation of the simple and common case on its own.