yahoo-eng-team team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

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