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
