Public bug reported:
Seen on live desktop isos build date:
Desktop live installer prefers NetworkManager backend for network config due to
a netplan config file /etc/netplan/01-network-manager.yaml which contains:
network:
version: 2
renderer: NetworkManager
livecd-rootfs configures cloud-init to write directly to
/etc/NetworkManager/system-connections when discovering network due to a config
snippet at
/etc/cloud/cloud.cfg.d/99-installer-use-networkmanager.cfg which sets
cloud-init to write directly to /etc/NetworkManager/system-connections with
this config:
# Automatically generated by installer build process
system_info:
network:
renderers: ['network-manager']
activators: ['network-manager']
-
This tells cloud-init to write out
/etc/NetworkManager/system-connections/cloud-init-enp1s0.nmconnection directly.
Later Ubuntu-desktop-installer(subiquity) starts, it may set network
config and write it to /etc/netplan/00-installer.yaml and trigger a
'netplan apply'.
If there is a non-empty netplan config at this time, subiquity writes out
/etc/netplan/00-installer.yaml and renames any other existing netplan yaml
files to /etc/netplan/*.yaml.dist-subiquity.
Then subiquity(ubuntu-desktop-installer) invokes netplan apply to render all
applicable network config to the ephemeral (installer) environment.
When netplan is rendering to `backend: NetworkManager` instead of the
default networkd and it'll write
/etc/NetworkManager/netplan-*.nmconnection files with connection names
scoped under `netplan-`. Cloud-init's rendered connections are scoped
under `cloudinit-`. This results in a split brain problem where
cloudinit's configuration and netplan's configuration are not aware of
each other and netplan isn't aware of any pre-existing
/etc/NetworkManager artifacts. We then have conflicting nm connections
being defined and named for the same underlying network interfaces. This
results in inability to run: nmcli load /etc/NetworkManager/system-
connections/cloud-init-enp1s0.nmconnection with errors such as "unknown
connection" or "ipv4.gateway: gateway cannot be set if there are no
addresses configured"
Ideally we probably want both cloud-init and subiquity to be configuring
network in netplan config files so that any merged network config is well known
by netplan and results in a single source of truth for network config.
This may mean dropping the overrides provided by livecd-roots setting
cloud-init to render directly to network-manager.
** Affects: cloud-init
Importance: Undecided
Status: New
** Affects: livecd-rootfs (Ubuntu)
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/2015605
Title:
desktop live installer: cloud-init/ubuntu-desktop-installer network
config naming collisions
Status in cloud-init:
New
Status in livecd-rootfs package in Ubuntu:
New
Bug description:
Seen on live desktop isos build date:
Desktop live installer prefers NetworkManager backend for network config due
to a netplan config file /etc/netplan/01-network-manager.yaml which contains:
network:
version: 2
renderer: NetworkManager
livecd-rootfs configures cloud-init to write directly to
/etc/NetworkManager/system-connections when discovering network due to a config
snippet at
/etc/cloud/cloud.cfg.d/99-installer-use-networkmanager.cfg which sets
cloud-init to write directly to /etc/NetworkManager/system-connections with
this config:
# Automatically generated by installer build process
system_info:
network:
renderers: ['network-manager']
activators: ['network-manager']
-
This tells cloud-init to write out
/etc/NetworkManager/system-connections/cloud-init-enp1s0.nmconnection directly.
Later Ubuntu-desktop-installer(subiquity) starts, it may set network
config and write it to /etc/netplan/00-installer.yaml and trigger a
'netplan apply'.
If there is a non-empty netplan config at this time, subiquity writes out
/etc/netplan/00-installer.yaml and renames any other existing netplan yaml
files to /etc/netplan/*.yaml.dist-subiquity.
Then subiquity(ubuntu-desktop-installer) invokes netplan apply to render all
applicable network config to the ephemeral (installer) environment.
When netplan is rendering to `backend: NetworkManager` instead of the
default networkd and it'll write
/etc/NetworkManager/netplan-*.nmconnection files with connection names
scoped under `netplan-`. Cloud-init's rendered connections are scoped
under `cloudinit-`. This results in a split brain problem where
cloudinit's configuration and netplan's configuration are not aware of
each other and netplan isn't aware of any pre-existing
/etc/NetworkManager artifacts. We then have conflicting nm connections
being defined and named for the same underlying network interfaces.
This results in inability to run: nmcli load
/etc/NetworkManager/system-connections/cloud-init-enp1s0.nmconnection
with errors such as "unknown connection" or "ipv4.gateway: gateway
cannot be set if there are no addresses configured"
Ideally we probably want both cloud-init and subiquity to be configuring
network in netplan config files so that any merged network config is well known
by netplan and results in a single source of truth for network config.
This may mean dropping the overrides provided by livecd-roots setting
cloud-init to render directly to network-manager.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2015605/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
