cloud-init schema --system reports success on non-parseable YAML #cloud-config

[Chad Smith]

cloud-init 22.4.2

cat > can-not-parse.yaml <<EOF
#cloud-config
a: [*]
EOF

lxc launch ubuntu-daily:lunar test-l -c user.user-data="$(cat can-not-parse.yaml)"
lxc exec test-l -- cloud-init status --wait --long
lxc exec test-l grep WARNING /var/log/cloud-init.log
lxc exec test-l -- cloud-init schema --system

--- expected results:
want an error from cloud-init schema --system

--- actual results:
csmith@uptown:~$ lxc exec test-l grep WARNING /var/log/cloud-init.log
2022-12-16 23:23:23,319 - util.py[WARNING]: Failed loading yaml blob. Invalid format at line 5 column 26: "while scanning an alias
2022-12-16 23:23:23,329 - util.py[WARNING]: Failed loading yaml blob. Invalid format at line 5 column 26: "while scanning an alias
2022-12-16 23:23:23,330 - cloud_config.py[WARNING]: Failed at merging in cloud config part from part-001: empty cloud config
csmith@uptown:~$ lxc exec test-l -- cloud-init schema --system
Valid cloud-config: system userdata

fun fact: using the new config setting `cloud-init.user-data` instead of `user.user-data` actually gets validated by LXD before instance launch. so you can't incorrectly configure cloud-init using new lxd cloud-init config keys.

The reason this cloud-init schema --system succeeds is because cloud-init resets user-data to an empty dict {} at /var/lib/cloud/instance/cloud-config.txt when it fails the load the #cloud-config YAML.

# cat /var/lib/cloud/instance/cloud-config.txt
#cloud-config

--- {}
...

I'd recommend that on new releases, this is undesirable behavior and that we should more strictly error out to make this condition discoverable.

[Chad Smith (chad.smith)]

This bug is reported as released in cloud-init 23.3. If it is still a probiem, please re-open this bug.