Correct how config_drive content is generated

[cjeanner]

It seems older cloud-init, as 22.1 exposed in RHEL-9.2, is having issues
with the way some of the content is generated, preventing to apply the
whole configuration.

Namely, in the libvirt_manager, we might have no network configuration;
but in the config_drive, a file was created with '' as content,
leading to cloud-init to crash (not a valid YAML dict).

This patch changes how configuration snippets are checked and generated.

The error as detected by cloud-init was as follow:

[    5.237126] cloud-init[744]: Cloud-init v. 22.1-9.el9 running 'init-local' at Mon, 09 Sep 2024 11:16:09 +0000. Up 5.21 seconds.
[    5.387470] cloud-init[744]: 2024-09-09 11:16:10,072 - util.py[WARNING]: Failed loading yaml blob. Yaml load allows (<class 'dict'>,) root types, but got str instead
[    5.389029] cloud-init[744]: 2024-09-09 11:16:10,072 - util.py[WARNING]: Getting data from <class 'cloudinit.sources.DataSourceNoCloud.DataSourceNoCloud'> failed

With newer cloud-init (23.x) as shipped by RHEL-9.4, the error wasn't
fatal and it was still continuing to apply the other files (in this
case, the user-data).
In earlier version, it was a hard stop.

Using cloud-init devel schema -c <config-file> also raised the missing
header:

[root@builder2 /]# cloud-init devel schema -c config_drive/meta-data
Error:
Cloud config schema errors: format-l1.c1: File config_drive/meta-data needs to begin with "#cloud-config"

And adding the header, but without any actual data, lead to:

[root@builder2 /]# cloud-init devel schema -c config_drive/network-config
Error:
Cloud-config is not a YAML dict.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[cescgina]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cescgina

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [cescgina]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hjensas]

meta-data and network-data files is not #cloud-config and should not have that header.

If you want to validate network-config you need to use the correct schema type: cloud-init schema -c network-config --schema-type network-config - I am not sure if there is a meta-data- validator implemented but I cannot see the #cloud-config header used in any examples of meta-data in cloud-init docs. But the header is used to identify the format used for cloud-config - see: https://github.com/canonical/cloud-init/blob/5d91e9639def8340387c4e370bf48d54657938a8/cloudinit/handlers/cloud_config.py#L40-L41

cloud-init schema --help
usage: /bin/cloud-init schema [-h] [-c CONFIG_FILE] [-t {cloud-config,network-config}] [-i INSTANCE_DATA] [--system] [-d DOCS [DOCS ...]] [--annotate]

optional arguments:
  -h, --help            show this help message and exit
  -c CONFIG_FILE, --config-file CONFIG_FILE
                        Path of the cloud-config or network-config YAML file to validate
  -t {cloud-config,network-config}, --schema-type {cloud-config,network-config}
                        When providing --config-file, the schema type to validate config against. Default: cloud-config
  -i INSTANCE_DATA, --instance-data INSTANCE_DATA
                        Path to instance-data.json file for variable expansion of '##template: jinja' user-data. Default: /run/cloud-init/instance-data.json
  --system              Validate the system instance-data provided as vendor-data user-data and network-config
  -d DOCS [DOCS ...], --docs DOCS [DOCS ...]
                        Print schema module docs. Choices: all or space-delimited cc_names.
  --annotate            Annotate existing instance-data files any discovered errors

[hjensas]

/lgtm