Public bug reported: As seen in <https://askubuntu.com/questions/1222752/how-to-get-out-of-a -netplan-rabbit-hole>, users who install with subiquity end up with a /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg that persists on the target system, plus an /etc/netplan/50-cloud-init.yaml that tells users not to edit it without taking steps to disable cloud-init.
I don't think this is what we want. I think a subiquity install should unambiguously treat cloud-init as a one-shot at installation, and leave the user afterwards with config files that can be directly edited without fear of cloud-init interfering; and the yaml files generated by cloud-init on subiquity installs should therefore also not include this scary language: # This file is generated from information provided by the datasource. Changes # to it will not persist across an instance reboot. To disable cloud-init's # network configuration capabilities, write a file # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: # network: {config: disabled} But we need to figure out how to fix this between subiquity and cloud- init. ** Affects: cloud-init Importance: Undecided Status: New ** Affects: subiquity Importance: Undecided Status: New ** Also affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1869967 Title: subiquity->cloud-init generates netplan yaml telling user not to edit it Status in cloud-init: New Status in subiquity: New Bug description: As seen in <https://askubuntu.com/questions/1222752/how-to-get-out- of-a-netplan-rabbit-hole>, users who install with subiquity end up with a /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg that persists on the target system, plus an /etc/netplan/50-cloud-init.yaml that tells users not to edit it without taking steps to disable cloud-init. I don't think this is what we want. I think a subiquity install should unambiguously treat cloud-init as a one-shot at installation, and leave the user afterwards with config files that can be directly edited without fear of cloud-init interfering; and the yaml files generated by cloud-init on subiquity installs should therefore also not include this scary language: # This file is generated from information provided by the datasource. Changes # to it will not persist across an instance reboot. To disable cloud-init's # network configuration capabilities, write a file # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: # network: {config: disabled} But we need to figure out how to fix this between subiquity and cloud- init. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1869967/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp