This bug was originally filed in Launchpad as LP: #1869967

affected_projects = ['subiquity']
assignee = None
assignee_name = None
date_closed = 2020-04-03T16:46:16.520597+00:00
date_created = 2020-03-31T21:35:55.980349+00:00
date_fix_committed = None
date_fix_released = None
id = 1869967
importance = undecided
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1869967
milestone = None
owner = vorlon
owner_name = Steve Langasek
private = False
status = invalid
submitter = vorlon
submitter_name = Steve Langasek
tags = []
duplicates = []

Launchpad user Steve Langasek(vorlon) wrote on 2020-03-31T21:35:55.980349+00:00

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.