We've begun to make progress on this ticket to improve the use-case for reusing live-installed images as the golden-image for cloning.
Because some network configuration values set during installer prompts, wifi passwords, require root-readonly netplan files to ensure that the wifi passwords aren't world-readable.
The cloud-init network renderers doesn't currently have the support in it's network renderers to emit root-readonly subsets of network configuration as separate netplan configuration file with different global permissions based on sensitive data.
As such, subiquity can't use cloud-init network configuration directly at the moment, but I've filed a separate low-weight bug to track this work as it will allow subiquity to use cloud-init's native networking in the future.
In the meantime, we currently have some pull requests coming together that will simplify the golden image creation in VMware a bit planned for the next release of cloud-init 22.3:
1. cloud-init to support a /etc/cloud/clean.d directory to run third party cleanup scripts when
`cloud-init clean` is called https://github.com/canonical/cloud-init/pull/1581
2. installer (subiquity) to deliver a /etc/cloud/clean.d/99-installer script which will automatically remove any network and DataSourceNone configuration artifacts to allow the installed image to be used for cloning https://github.com/canonical/subiquity/pull/1347
Any comments or suggestions welcome as we close out on these initial improvements.
Hi again pengpengs and yhzou,
Thanks for your patience on this issue.
We've begun to make progress on this ticket to improve the use-case for reusing live-installed images as the golden-image for cloning.
Because some network configuration values set during installer prompts, wifi passwords, require root-readonly netplan files to ensure that the wifi passwords aren't world-readable.
The cloud-init network renderers doesn't currently have the support in it's network renderers to emit root-readonly subsets of network configuration as separate netplan configuration file with different global permissions based on sensitive data.
As such, subiquity can't use cloud-init network configuration directly at the moment, but I've filed a separate low-weight bug to track this work as it will allow subiquity to use cloud-init's native networking in the future.
In the meantime, we currently have some pull requests coming together that will simplify the golden image creation in VMware a bit planned for the next release of cloud-init 22.3:
1. cloud-init to support a /etc/cloud/clean.d directory to run third party cleanup scripts when /github. com/canonical/ cloud-init/ pull/1581 clean.d/ 99-installer script which will automatically remove any network and DataSourceNone configuration artifacts to allow the installed image to be used for cloning /github. com/canonical/ subiquity/ pull/1347
`cloud-init clean` is called
https:/
2. installer (subiquity) to deliver a /etc/cloud/
https:/
Any comments or suggestions welcome as we close out on these initial improvements.