[Bug]: Empty cloud-init parts can be returned by cloud-init

[njones-lanl]

Describe the bug

Cloud-init can return a cloud-config of type text/cloud-config with no modules being called. This causes the cloud-init run to fail with something like:

[root@ha07 ~]# cloud-init status --long
status: error
extended_status: error
boot_status_code: enabled-by-generator
last_update: Thu, 18 Sep 2025 22:21:09 +0000
detail:
DataSourceNoCloudNet [seed=cmdline,ds_config_seedfrom,http://10.0.0.1:27777/cloud-init][dsmode=net]
errors:
        - ('write_files', TypeError("'NoneType' object is not iterable",))
        - ('write_files_deferred', TypeError("'NoneType' object is not iterable",)) 
recoverable_errors:
WARNING:
        - Failed at merging in cloud config part from part-001: empty cloud config
        - Failed at merging in cloud config part from part-015: empty cloud config
        - Failed at merging in cloud config part from part-016: empty cloud config
        - Running module write_files (<module 'cloudinit.config.cc_write_files' from '/usr/lib/python3.6/site-packages/cloudinit/config/cc_write_files.py'>) failed
        - Device '/dev/overlay' did not exist. cannot resize: dev=overlay mnt_point=/ path=/
        - Running module write_files_deferred (<module 'cloudinit.config.cc_write_files_deferred' from '/usr/lib/python3.6/site-packages/cloudinit/config/cc_write_files_deferred.py'>) failed
        - /etc/ssh/ssh_host_dsa_key.pub: failed to open, can not phone home that data!

part-001 is unfortunately always empty, and is where the metadata comes in. It isn't of type text/cloud-config though, unlike part-015 and part-016 in these cases, which look like:

[root@ha07 ~]# tail /var/lib/cloud/instance/vendor-data.txt.i
Content-Disposition: attachment; filename="part-015"

#cloud-config
--===============4039836530091675151==
MIME-Version: 1.0
Content-Type: text/cloud-config
Content-Disposition: attachment; filename="part-016"

#cloud-config
--===============4039836530091675151==--

Is it possible to have cloud-init do some very light linting on GET and not return empty text/cloud-config (perhaps a no-op error that points out which group is empty, but still shows up in /var/lib/cloud/instance/vendor-data.txt.i) ?

Steps to reproduce

1. submit a group with type text/cloud-config to cloud-init, but no module
2. run a compute node through cloud-init
3. fail to complete cloud-init

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct