Thank you for this bug and making cloud-init better and for the additional commit reference as a guess for when regression was introduced.
You are correct that I reintroduced SafeDumper default and that's what broke the cloud-init devel net-convert command.
Because the original commit cf30836645473c62599e838ab48b2d31677fa584 had inadvertently switched to using yaml.Dumper when dropping the direct yaml.safe_dump() call we deemed it reasonable to switch that dumper back to the original SafeDumper as all runtime callsites provide only simple types and not python objects.
Turns out, the command `cloud-init devel net-convert --debug` does attempt to stuff in a python object as you noted NetworkState.
I have reviewed all runtime call-sites to cloudinit.safeyaml.dumps and all of the objects that cloud-init currently provides are dictionaries of simple dicts with the exception of this devel --debug command.
Thank you for this bug and making cloud-init better and for the additional commit reference as a guess for when regression was introduced.
You are correct that I reintroduced SafeDumper default and that's what broke the cloud-init devel net-convert command.
Because the original commit cf30836645473c6 2599e838ab48b2d 31677fa584 had inadvertently switched to using yaml.Dumper when dropping the direct yaml.safe_dump() call we deemed it reasonable to switch that dumper back to the original SafeDumper as all runtime callsites provide only simple types and not python objects.
Turns out, the command `cloud-init devel net-convert --debug` does attempt to stuff in a python object as you noted NetworkState.
I have reviewed all runtime call-sites to cloudinit. safeyaml. dumps and all of the objects that cloud-init currently provides are dictionaries of simple dicts with the exception of this devel --debug command.
Here is an upstream PR to fix this one callsite and add a unit test so we recognize this type of failure in the future. https:/ /github. com/canonical/ cloud-init/ pull/1484